Re: GUERRE ST-AMIGA, FIGHT !!!

[babsimov]

Mon Dieu, mon Dieu...

Confondre SoundBlaster et AdLib, c'est quand même une hérésie ; Surtout, lorsque l'oeuvre musicale de Dune a été sécialement composée pour ce chip son.

Mais je ne confonds pas, je sais très bien que Dune a été composé pour la Adlib. Crois moi j'ai tellement aimé ces musiques que je me suis renseigné. Ils avaient réécris le pilote si je me souviens bien de mes lectures et même les ingénieurs d'Adlib n'arrivaient pas à croire que leur carte sortait ça.

Mon propos en choisissant Dune, comme je l'ai expliqué à Youki, c'était pour montrer que, pour splendides que sont ces musiques, les instruments sonnent "creux" face aux samples Amiga. Et ça c'est en 1992, c'est à dire que le standard son des jeux ce n'est pas la soundblaster, mais la Adlib, même s'il avait une soundblaster en 1990, un PC de l'époque ne sortait pas du son meilleur qu'un Amiga (pourtant avec un composant sonore vieux de 5 ans). Son jeu type Amiga c'est 1994. 

Sur Amiga, que dire. Ce n'est pas l'original, il manque plein d'instrumentation dans les thèmes... A vrai dire, il manque surtout plein de thèmes. Un musicien ne s'y tromperait pas à croire qu'un sample (que le port imprimante d'un PC peut mieux restituer que le chip son de l'Amiga), pourrait feindre une composition harmonieuse.

Et je suis d'accord avec toi sur ce point, ils manquent des voies sur les versions Amiga des musiques. Elles sonnent plus "vraies" que sur PC, mais les versions PC sont plus "complètes" en terme de composition. Pour les musiques qui manquaient, c'était aussi une de mes grosses déceptions de la version Amiga. Je les attendais moi ces musiques que je connaissais par coeur pour les avoir écouté et réécouté. J'espérais bien que le son plus "vrai" de l'Amiga leur rendrait justice. Je n'ai eu que 3 d'entre elles et en plus pas spécialement mes préférés 

Enfin... Dune, est pourtant un excellent choix de comparaison entre Amiga et PC.
Ne serait-ce parce que, sorti en 1992, il est le symbole de la décadence de l'Amiga.

- 32 couleurs sur Amiga, contre 256 sur PC.
- 3 musiques sur Amiga (2 in-game) contre une dixaine sur PC.
- Pauvre disquette sur Amiga, CD-ROM + survol du désert sur PC.
- Etc.

Pareil, je suis d'accord ! J'avais un disque dur moi sur mon 500, de quel droit parce qu'une bonne partie de utilisateur d'Amiga n'en avaient pas je n'aurais pas eu droit à avoir ces musiques en bonus ? Quelle était la récompense d'avoir un disque dur sur Amiga ? Sur ce coup là j'en ai voulu à Commodore de ne pas avoir fait ce qu'il fallait pour que le disque dur soit plus répandu sur 500.

La version CD-ROM avec survol en 3D précalculée sur PC c'est aussi un peu plus tard. Il y a eu une rumeur de version CD32 aussi.

La version Amiga était très bien quand on avait un A500. Rien à dire...
Mais quand on venait d'acheter un A1200/4000, se taper ça c'était une honte.

J'étais quand même bien content d'y jouer à Dune sur mon Amiga (même 1200). Bien sur qu'une version AGA aurait été un must.

Et les grandes gueules de la communauté Amiga, pendant 25 ans  (1/4 de siècle !) elle brasse du vent...
C'est quand que vous vous sortez les doigts, pour faire une version AGA depuis les ressouces originales ?
Pourtant, comme dirait jamysylver : "c'est pas sourcier !"  
Avec tant de compétence sur Amiga, redéfinir le mode graphique AGA et injecter les gfx 256 couleurs de la version PC, ça doit se faire en un rien de temps ?  Puis les musiques, aujourd'hui il suffit de chopper l'OST CD et carément sampler l'audio et faire une version installable sur disque dur, à défaut d'une version CD-32 ? (idem pour insérer les séquences du désert, hein)

Et ça, mon Dieu, oui là... Vous pourrez vous targer d'être fiert d'avoir la version ultime du jeu.  
En attendant, bah... C'est quand même une tout autre classe sur PC. 

Je te rejoint complétement. D'ailleurs, sur ce sujet, il y a déjà un bon moment quand j'avais évoqué les musiques de Dune, j'avais finalement demandé exactement ce que tu demandes, une version AGA avec les musique du CD, au même titre qu'il a bien été fait une version AGA de Wing Commander (sans akiko).

Je crois même me souvenir que j'avais demandé si c'était faisable à dlfrsilver à l'époque et qu'il m'avait dit probablement mais que c'était un gros travail.

Ca aurait été normal que Dune sur Amiga ait une meilleur note que sur PC, puisque c'est plus impressionnant pour la machine.

Non, pas d'accord, je trouve Joystick cohérent au contraire. Dune sur PC a été une claque tant par sa réalisation, son gameplay et ses musiques plus qu'étonnantes en terme de qualité. 

Sur Amiga ce n'était qu'un portage, il manquait des musiques, moins de couleurs, donc non la différence de 5 % en moins pour l'Amiga me parait tout à fait justifié.

youki

Quand au multitache preemptif , tu peux le faire sur n'importe quel processeur. Apres c'est juste plus ou moins chiant a faire.

Ben non, sur le 6502 il semble que même de nos jours ça n'existe pas, c'est ce qu'expliquait Stapha92. Ce serait possible mais ça ramerait énormément.

ah ben , apres une petite recherche, j'ai trouvé un "unix" like pour C64 et C128  avec multitache preemptif.   "LUnix"

Les infos ici ,si ca t'interesse.

http://lng.sourceforge.net/

Effectivement info intéressante, j'ai survolé pour l'instant, mais j'irais lire ça plus attentivement plus tard.

Merci pour l'information.

ah ben , apres une petite recherche, j'ai trouvé un "unix" like pour C64 et C128  avec multitache preemptif.   "LUnix"
Les infos ici ,si ca t'interesse.

http://lng.sourceforge.net/

Il y a un Windows like (SymbOS) pour MSX, CPC, PCW, qui fait du multitache. On en a déjà parlé ici même... Mais amigalzheimer.

Ben non, le lien que j'avais donné pointait pile sur l'explication de Stapha92 qui évoque SymbOS, donc Amigalzheimer je trouve c'est un peu déplacé. Il t'aurait suffit de cliquer sur le lien que j'avais donné pour le voir. Troll, moi je dirais 

Et je cite à nouveau :

https://www.gamopat-forum.com/t82337p150-guerre-st-amiga-fight#2181267

"Pour le débat sur le multitache en général. 

Rocky a raison : on peut faire du multitache avec toutes les machines (ou presque...). 
Maintenant quand il dit que ce n'était pas une révolution sur le mig et qu'il parle du multitache sur 800XL, faut juste mentionner que en 2015, ça n'existe toujours pas. 
Sur le mig c'était dispo il y a 30 ans (bon dans ce cas précis, je dirai qu'il fait de l'humour en nous faisant découvrir un truc interessant sur une autre machine). 
Il y a aussi SymbOS : OS multitache préemptif dédié au Z80... Et sorti 20 ans après l'AmigaOS... 



Si un OS multitache sur un Z80 avec 128 Ko est possible, cela ne signifie-t-il pas que la même chose sur un 68000 et 512 Ko est exploitable ? 

Par contre, je suis d'accord avec le fait que le ST aurait pu avoir un OS multitache dès le début. Rien dans son architecture l'en empeche. 
Je dirai même plus : vu la machine que c'est, il aurait mérité d'avoir mieux que ce TOS qui n'est qu'un cp/m cuisiné à la sauce 16 bits en vitesse. 

Franchement, quand on voit ça sur C64 : 



Quoi !!! Des noms longs ! Des icones personnalisés et en couleur ! C'est dingue : le GEM est incapable de faire quelque chose que faisait un OS sur 8 bits alors qu'ils étaient contemporains... Oui oui ! Je ne parle pas d'un OS sorti sur C64 20 ans après ! 


Alors, le multitache est-il possible sur toutes les machines ? 

Pour répondre, étudions le fonctionnement : 

Lorsqu'un programme fonctionne, il mémorise tout un tas de valeurs dans les registres processeurs. Donc lorsque l'OS va l'interrompre pour basculer sur une autre tache, il faudra qu'il sauvegarde tous ces registres afin de les restaurer quand il va rendre la main à cette tache. Mais il y également d'autres registres qui ne sont pas utilisés pour stocker des valeurs mais certaines infos nécessaires au fonctionnement du processeur. Par exemple les bits d'états, ou le PC (qui contient l'adresse de l'instruction en cours). 
Voilà donc la première condition pour faire du multitache : 
        - Le processeur doit permettre la sauvegarde/restauration de TOUS ses registres. 
Le nombre de registres n'étant pas illimité, un programme va également stocker des valeurs en mémoire. Il peut le faire en se réservant une zone mémoire dans laquelle il va stocker ces valeurs. Cela ne pose aucun problème dans un OS multitache : chaque programme aura réservée sa propre zone. Mais il peut le faire également en utilisant ce que l'on appelle une pile (parfois c'est obligatoire car il y a des processeurs qui ne peuvent faire certaines opérations que sur les valeurs stockées dans la pile). Il s'agit d'une zone mémoire dans laquelle on stocke des valeurs "l'une sur l'autre". D'ou le terme de pile : c'est comme une pile d'assiette. On peut toujours accéder à la dernière assiette ajoutée (les autres aussi mais pas aussi facilement...). Lire la derniere valeur de la pile revient à retirer l'assiette du haut. Ecrire une valeur dans cette pile revient à ajouter une assiette. 
Donc un OS multitache devra également sauvegarder le contenu de la pile du programme qu'il doit interrompre (et la restaurer quand il lui rend la main). C'est là que les problèmes commencent : Sauvegarder les registres processeurs va vite, car il n'y en a pas beaucoup. Les piles sont beaucoup plus grandes : si l'os doit vraiment faire ça de cette façon, le basculement d'une tache à l'autre va prendre beaucoup de temps et on va se retrouver avec un os qui tourne au ralenti... 
Comment faire ? Et bien c'est simple : au lieu de sauver/restaurer la pile, on va la mettre à un endroit différent pour chaque processe en cours d'exécution. Le programme 1 utilisera une pile située à l'adresse X, le programme 2 utilisera une pile située à l'adresse Y, etc... 
Comment implémenter ça ? 
Avec un Z80, la position de la pile est stockée dans un registre 16 bits (SP = Stack Pointer). Chaque programme pourra se voir allouer une zone mémoire différente pour sa pile au moment de son lancement. L'OS s'en occupera. Tout comme il s'occupera de mettre cette adresse dans le registre SP avant de donner la main au programme à lancer. Il va reserver une certaine taille. Comme il ne sait pas de quel taille le programme à lancer a besoin, il peut le faire de façon arbitraire ou en fonction d'un paramètre associé à un programme à lancer. C'est pourquoi on parle parfois de taille de pile sur des OS comme UNIX : il s'agit de cette fameuse zone. 
Avec un 68000, c'est pareil. A la différence que l'adresse qui est stockée est sur 32 bits. 
Grace à ça, le simple fait de stocker/restaurer tous les registres processeur va permettre de gérer une pile différente pour chaque process. 
Et le 6502 ? Et bien il pose un problème : le registre de pile ne contient qu'un octet. Or les adresse du 6502, comme celles du Z80, sont stockées sur 16 bits, soit 2 octets. Comment fait-il ? C'est simple : le 6502 considère toujours que le premier octet de l'adresse de la pile vaut 1. Cela revient à dire que pour avoir l'adresse réelle de la pile, il faut toujours ajouter la valeur 256 à celle qui est stockée. Donc la pile d'un 6502 sera toujours située entre les adresse 256 et 511 pour des valeurs de son registre qui iront de 0 à 255. 
Du coup, il n'y a aucun moyen de forcer le 6502 à stocker sa pile ailleurs. 

En résumé, la pile d'un Z80 ou d'un 68000 est relocalisable. Pas celle du 6502. 
Donc, pour faire du multitache avec le 6502, il faudra sauver/restaurer 256 octets (1024 accès mémoire...) à chaque basculement de tache. Ce qui va donner un os qui rame. Le seul moyen de s'en sortir est d'utiliser un système de banque mémoire. Mais il faut un hardware dédié. 
C'est pourquoi SymbOS existe pour les ordinateurs à base de Z80 depuis 2006 alors que l'atari800 attend toujours... 

Donc à la question "peut-on faire du multitache avec n'importe quel ordinateurs?" : la réponse est "oui si son processeur permet la sauvegarde/restauration de tous ses registres". 
Et à la question "peut-on faire du multitache de façon exploitable avec n'importe quel ordinateurs ?" : la réponse est "oui si, en plus, son processeur possède une pile relocalisable".

Donc, au final, ça ne dépend que du processeur."

concernant dune, L'idée de le passer en AGA, pourquoi pas :)
Par contre, on laisse les musiques bidons de la version PC, et on garde les belles musiques Amiga, et on rajoute celles qui manquent 
Et voilàààà :)

Les musiques Amiga sont vieillottes aujourd'hui... Il faut partir de l'OST CD et la jouer (CD32) ou la streamer (8SVX).

Je l'ai ce CD, il a tourné en boucle un bon moment chez moi dans les semaines (voir mois) qui ont suivi son achat 
Et j'ai toujours plaisir à l'écouter de temps en temps, tout comme les musiques Soundblaster (Adlib), par contre les musiques Amiga de Dune n'évoquent au final pas trop de nostalgie pour moi.

Quant a l'OS multitache sur un 6502  , il n'y en a pas encore, car ca ne presente aucun interet , je pense.  Mais je suis sur que si on veut , on peut le faire.

C'est fait ! 

Mais comme tu le dis, ça n'a aucun intérêt

Merci pour l'information. L'intérêt, le fun et la prouesse technique je pense.

Dommage que l'on ne soit pas vendredi... 

Au fait, as tu vu ma réponse sur l'Alpha ? J'aimerais bien ton avis. Merci.

D'ailleurs vous en pensez quoi de ce calcul de ratio de puissance entre Alpha et PA-RISC ? Youki ? TotOOntHeMooN ? Je me suis trompé dans mes calculs ? C'est cohérent ?

concernant dune, L'idée de le passer en AGA, pourquoi pas :)

Par contre, on laisse les musiques bidons de la version PC, et on garde les belles musiques Amiga, et on rajoute celles qui manquent 

Et voilàààà :)

Est ce que tu te rappels qu'on avait abordé ça ici il y a un bon moment ? Tu vois qu'il y a une demande, ça pourrait être un projet à réaliser tôt ou tard non ? Voir même la version CD (avec 3D précalculée et les voix) sur Amiga génération AGA 
Ce qui serait encore plus fort ce serait d'avoir les vidéo du films (présent sur la version CD), mais en français. Je pense me souvenir que c'était uniquement en anglais sur le CD PC pour ces scènes de film ?

Je veux dire ce genre de vidéo :



J'ai trouvé je crois une version open source de Dune :
https://github.com/OpenDUNE/OpenDUNE

Donc un portage de ça mais avec tout ce que j'ai dit en plus ce serait cool non ?

[Zarnal]

Rocky, Guru...

[TotOOntHeMooN]

Je l'ai ce CD, il a tourné en boucle un bon moment chez moi dans les semaines (voir mois) qui ont suivi son achat 

Je l'ai toujours aussi... D'ailleurs, il vaut mieux vu le prix qu'il coute aujourd'hui d'okaz... 

On avait commencé avec un amis à étudier le portage de Dune pour CD32 + A1200HD il y a 5 ans de cela.
Il n'y a pas tant de travail, mais ça demande quand même de s'y investir et l'envie de faire plaisir.

[babsimov]

Je l'ai ce CD, il a tourné en boucle un bon moment chez moi dans les semaines (voir mois) qui ont suivi son achat 

Je l'ai toujours aussi... D'ailleurs, il vaut mieux vu le prix qu'il coute aujourd'hui d'okaz... 

On avait commencé avec un amis à étudier le portage de Dune pour CD32 + A1200HD il y a 5 ans de cela.
Il n'y a pas tant de travail, mais ça demande quand même de s'y investir et l'envie de faire plaisir.

Je sais pas combien il coute d'occasion, mais il était déjà rare à sa sortie 
Tout ceux à qui j'en avais parlé me disaient qu'il n'était jamais sortit 

Je peux t'assurer qu'un portage ferais plaisir, surtout avec les ajouts des vidéo en français que j'ai indiqué (j'ai édité ma réponse entre temps). J'ai même trouvé une version open source de Dune on dirait.

EDIT : en fait ça semble être une version open source de DuneII. J'ai jamais trop compris pourquoi Dune II est mieux considéré que Dune ? Pour moi Dune (le 1) était largement plus fidèle à l'oeuvre que Dune II qui n'utilisait que l'univers comme base, mais je ne m'y suis pas retrouvé. Je dis pas que je n'ais pas eu plaisir à jouer à Dune II pour autant.

[TotOOntHeMooN]

La vidéo d'intro existe sut Mega-CD, mais je ne sais pas pour PC ?
Concernant Dune II, simplement parce qu'il a inventé le genre STR.

[babsimov]

La vidéo d'intro existe sut Mega-CD, mais je ne sais pas pour PC ?

J'ai regardé sur youtube, on dirait que non. Sinon il suffit de la digitaliser, il y a des player de vidéo sur Amiga non ? Si vous le faites, de grâce, essayez d'avoir les vidéos en français, ou même d'avoir l'anglais le français et les autres langues du jeu pour l'intro.

Là l'Amiga aurait la version ultime 

[TotOOntHeMooN]

Il me semble que c'est Sega qui avait raqué pour avoir le français sur la vidéo.
Après, il faut récup la vidéo PC et le son MD, et générer une vidéo Amiga.

[ryosaeba]

Comment peux-tu dire que M-Coder est le meilleur codeur sur ST ? Il y a en plein Manikin des TLB, Gunstick de ULM, Nick de TCB, Leonard......

[babsimov]

Il me semble que c'est Sega qui avait raqué pour avoir le français sur la vidéo.
Après, il faut récup la vidéo PC et le son MD, et générer une vidéo Amiga.

J'ai regardé sur youtube, mais on dirait qu'il n'y a pas les vidéo sur Sega CD et que c'est en anglais ?

PS : C'est pas toi qui avait dit sur un sujet ici que tu préparais un jeu qui pousserait l'AGA au delà de ce qu'il a été ?

EDIT : en fait c'est en français pour les dialogues sur Sega CD :



En tout cas, il me parait évident qu'avoir ces voix en français pour les personnages est un must pour la version ultime :)

Ah si en fait les vidéos sont en français sur MegaCD, mais si j'ai bien entendu, les musiques de sont pas celle du CD de Stephane Picq ?


La qualité de la vidéo était surement bien à l'époque, mais tant qu'à faire j'aimerais bien une qualité plus "moderne".

[babsimov]

Oui je l'ai trouvé juste avant de lire ta réponse 

Et du coup je t'ai mis un petit avis sur la vidéo avec une petite demande à ce sujet 

Ben quoi fallait pas me faire miroiter une version Amiga ultime, je l'attends depuis longtemps celle là 

D'ailleurs c'est comme les secret missions 1 et 2 pour Wing Commander Amiga, si quelqu'un pouvait porter ça un jour, ce serait cool pour toute la communauté Amiga je pense.

[TotOOntHeMooN]

Voilà, c'est la vidéo avec la voix en français.
Je n'ai jamais dit que le jeu sur Mega-CD utilisait les musiques de l'OST... 

[babsimov]

Voilà, c'est la vidéo avec la voix en français.
Je n'ai jamais dit que le jeu sur Mega-CD utilisait les musiques de l'OST... 

J'avais surement mal lu ou lu trop vite 

Alors cette version ultime c'est pour 2018 ?

Et le jeu qui poussera l'AGA à fond c'était toi ?

[TotOOntHeMooN]

Je ne penses pas avoir dit cela, surtout que je n'ai plus l'envie de faire des choses sur Amiga pour le moment.

[babsimov]

Je ne penses pas avoir dit cela, surtout que je n'ai plus l'envie de faire des choses sur Amiga pour le moment.

Je confonds peut être alors pour l'AGA.

Avec ce que tu dis, la version ultime de Dune sur Amiga me parait de plus en plus lointaine 

Quel dommage.

TotOOntHeMooN
Concernant Dune II, simplement parce qu'il a inventé le genre STR.

Bien sur il a inventé le STR, mais en terme de jeu "Dune", il tombait à côté. Alors que Dune (le 1) c'était un bijou à tous les niveaux et pas du "bourrinage" je trouve, comme au final Dune II l'était. 

Dune avait comme on dit la "french touch" 

[TotOOntHeMooN]

On ne peut pas tout faire et les priorités sont souvant liés aux opportunités...
J'aimerai que se soit fait par des passionnés d'Amiga il y a 10 ans.

[babsimov]

On ne peut pas tout faire et les priorités sont souvant liés aux opportunités...
J'aimerai que se soit fait par des passionnés d'Amiga il y a 10 ans.

Je pensais que ta discussion au sujet de ce Dune ultime n'était pas aussi ancienne. Je comprends que tes priorités ont changé, ne te méprends pas.

Mais peut être que dlfrsilver va pouvoir faire ça ?

[Zarnal]

Turrican 3 aga ou rien...

[babsimov]

Un peu de hors sujet, en cherchant Dune sur youtube je suis tombé sur ça :



C'est sortit en vidéo ça ? Parce que j'aimerais bien voir ça.

C'est une version officielle du film ? Un remasteurisation ?

EDIT : on dirait que quelqu'un prépare un remake de dune 1 :

[babsimov]

Turrican 3 aga ou rien...

Turrican j'accrochais pas. Non, je préférerais un jeu style Battle Squadron mais poussant l'AGA à fond.

[Zarnal]

Turrican 3 aga ou rien...

Turrican j'accrochais pas. Non, je préférerais un jeu style Battle Squadron mais poussant l'AGA à fond.

L'AGA a t'il un fond d'ailleurs ? A première vue, non...

Tout ce qui pourra être poussé à fond au mieux de nos jours sur Amiga c'est AMOS, et on en est encore très loin du fond (d'AMOS).

Suis-je compréhensible dans mon propos ?

Cela me ferait presque acheter un ST et cela me fait vraiment mal d'écrire cela. Encore un problème de fond...

[babsimov]

Turrican 3 aga ou rien...

Turrican j'accrochais pas. Non, je préférerais un jeu style Battle Squadron mais poussant l'AGA à fond.

L'AGA a t'il un fond d'ailleurs ? A première vue, non...

Tout ce qui pourra être poussé à fond au mieux de nos jours sur Amiga c'est AMOS, et on en est encore très loin du fond (d'AMOS).

Suis-je compréhensible dans mon propos ?

Cela me ferait presque acheter un ST et cela me fait vraiment mal d'écrire cela. Encore un problème de fond...

L'AGA doit bien avoir des possibilités jusqu'à nos jours inexploitées en jeu ? C'est certain qu'on ne peut pas espérer autant d'exploit sur AGA qu'il y en eut sur OCS cependant.

Je ne comprends pas bien la remarque pour AMOS ?

Ta dernière phrase est façon élégante de dire qu'en faite un ST ne "vaut rien" face à un Amiga 

[Zarnal]

Je vous laisse la nuit pour méditer sur mon propos.

[ChistopheS]

Je l'ai ce CD, il a tourné en boucle un bon moment chez moi dans les semaines (voir mois) qui ont suivi son achat 

Je l'ai toujours aussi... D'ailleurs, il vaut mieux vu le prix qu'il coute aujourd'hui d'okaz... 

On avait commencé avec un amis à étudier le portage de Dune pour CD32 + A1200HD il y a 5 ans de cela.
Il n'y a pas tant de travail, mais ça demande quand même de s'y investir et l'envie de faire plaisir.

J'aime bien ta dernière idée   Logiquement ça ne se fera donc jamais, vu le niveau de médiocrité et d'antipathie suscitée par la communauté 'Amiga vaincra'.

J'ai lu la description pour un OS multitâche.
Il manque la capacité du CPU à rapidement gérer les interruptions, et avoir des instructions non interruptibles pour gérer les sémaphores. (Ca c'est pour qui vous savez qui pense que je n'ai jamais rien codé et que je viendrais m'abaisser à discuter ici avec mon vrai pseudo).

@Babsimov l'AGA c'est du raté.
Compte sur les cartes accélératrices pour corriger les niaiseries de Commodore.
Chipset d'origine à chier (j'adopte la dlfrsilver attitude, le modo semble trouver ça cool) vive les cartes accélératrices dont un tiers de la puissance va servir à compenser la crotte chipsetique au coeur des machines Amiga.
(C'est tellement beau de faire du C2P et du mixage temps réel vers les 4 ridicules canaux de Paula).
En fait l'Amiga c'était la même daube que le PC Windows tant critiqué : une architecture moisie où les performances du CPU sont bouffées pour des trucs idiots.

[chacs]

Y a pas longtemps j'étais dans un petit resto et qu'est-ce que j'entends la musique du jeu Dune qui tourne en fond, c'était la version Adlib. Vraiment surpris, je demande au gars du resto, et il me dit que c'est un fan de jeu vidéo. Je lui dit qu'il existe aussi une version CD, mais il me répond que c'est cette version qu'il préfère. Pourtant le gars est jeune et n'a pas connu le jeu à l'époque.
Je pense aussi que c'est de loin la meilleure version.

Franchement j'adore l'Amiga, quand je réécoute les musiques amiga, ça a vraiment mal vieilli.

[TotOOntHeMooN]

Après tout, ce n'est pas étonnant. C'est une version instrumentale qui sonne "classique".
C'est un autre genre et finalement très bien pour une musique de fond pour un resto.

Et oui, l'Amiga paye sont avance technologique... Aujourd'hui ça sonne vieillot.
Ce n'est pas un reproche, c'est juste l'oreille qui n'est plus réceptive à cela.

[Zarnal]

Turrican 3 aga ou rien...

Turrican j'accrochais pas. Non, je préférerais un jeu style Battle Squadron mais poussant l'AGA à fond.

L'AGA a t'il un fond d'ailleurs ? A première vue, non...

Tout ce qui pourra être poussé à fond au mieux de nos jours sur Amiga c'est AMOS, et on en est encore très loin du fond (d'AMOS).

Suis-je compréhensible dans mon propos ?

Cela me ferait presque acheter un ST et cela me fait vraiment mal d'écrire cela. Encore un problème de fond...

L'AGA doit bien avoir des possibilités jusqu'à nos jours inexploitées en jeu ? C'est certain qu'on ne peut pas espérer autant d'exploit sur AGA qu'il y en eut sur OCS cependant.

Je ne comprends pas bien la remarque pour AMOS ?

Ta dernière phrase est façon élégante de dire qu'en faite un ST ne "vaut rien" face à un Amiga 

Pas vraiment, sous cette tournure " élégante ", j'informe que le simple fait de devoir acheter un atari ST(E) juste pour avoir des trucs intéressants pourrait potentiellement me faire mal à l'arrière train. Souci de fond en somme.

[beeAware]

youki

Quand au multitache preemptif , tu peux le faire sur n'importe quel processeur. Apres c'est juste plus ou moins chiant a faire.

Ben non, sur le 6502 il semble que même de nos jours ça n'existe pas, c'est ce qu'expliquait Stapha92. Ce serait possible mais ça ramerait énormément.

...

Grace à ça, le simple fait de stocker/restaurer tous les registres processeur va permettre de gérer une pile différente pour chaque process. 
Et le 6502 ? Et bien il pose un problème : le registre de pile ne contient qu'un octet. Or les adresse du 6502, comme celles du Z80, sont stockées sur 16 bits, soit 2 octets. Comment fait-il ? C'est simple : le 6502 considère toujours que le premier octet de l'adresse de la pile vaut 1. Cela revient à dire que pour avoir l'adresse réelle de la pile, il faut toujours ajouter la valeur 256 à celle qui est stockée. Donc la pile d'un 6502 sera toujours située entre les adresse 256 et 511 pour des valeurs de son registre qui iront de 0 à 255. 
Du coup, il n'y a aucun moyen de forcer le 6502 à stocker sa pile ailleurs. 

En résumé, la pile d'un Z80 ou d'un 68000 est relocalisable. Pas celle du 6502. 
Donc, pour faire du multitache avec le 6502, il faudra sauver/restaurer 256 octets (1024 accès mémoire...) à chaque basculement de tache. Ce qui va donner un os qui rame. Le seul moyen de s'en sortir est d'utiliser un système de banque mémoire. Mais il faut un hardware dédié.

Non, ce n'est pas tout à fait exact : la pile du 6502, et plus exactement la stack pointer, est bien relocalisable mais seulement sur 256 bytes (cf. instructions TXS et TSX du CPU). Ce qui signifie qu'il est possible de faire du multitasking sans avoir à sauvegarder/restaurer la pile à chaque basculement de tâche : mais les piles auront une taille limitée (par exemple, 8 tâches max avec 32bytes/pile).

[babsimov]

Je l'ai ce CD, il a tourné en boucle un bon moment chez moi dans les semaines (voir mois) qui ont suivi son achat 

Je l'ai toujours aussi... D'ailleurs, il vaut mieux vu le prix qu'il coute aujourd'hui d'okaz... 

On avait commencé avec un amis à étudier le portage de Dune pour CD32 + A1200HD il y a 5 ans de cela.
Il n'y a pas tant de travail, mais ça demande quand même de s'y investir et l'envie de faire plaisir.

J'aime bien ta dernière idée   Logiquement ça ne se fera donc jamais, vu le niveau de médiocrité et d'antipathie suscitée par la communauté 'Amiga vaincra'.

"médiocrité" "antipathie" là aussi j'ai l'impression d'un déjà lu, tout comme la remarque "la communauté Amiga Vaincra"... 
La communauté Amiga dont tu parles à maintes fois fait preuves de son bon niveau, tant en productions (software et hardware), qu'en terme d'entraide.
Tu sembles en avoir "gros sur la patate" contre l'Amiga toi aussi... encore une impression de déjà vu 

J'ai lu la description pour un OS multitâche.
Il manque la capacité du CPU à rapidement gérer les interruptions, et avoir des instructions non interruptibles pour gérer les sémaphores. (Ca c'est pour qui vous savez qui pense que je n'ai jamais rien codé et que je viendrais m'abaisser à discuter ici avec mon vrai pseudo).

Tiens, c'est étonnant ça que tu dises que tu as codé.

Sur ce sujet tu disais que tu étais pas codeur et maintenant tu as déjà "codé" (de bon niveau semble t il). Je suis surpris par ce "double langage"... Ta remarque vient, pour moi, au contraire renforcer le doute sur ton pseudo du coup.

https://www.gamopat-forum.com/t92194p960-guerre-st-amiga-fight#2738536

Je te cite :

"Je ne suis peut être pas codeur, mais je comprends comment tourne une machine et quels vont être ses points forts et ses points faibles."

EDIT de relecture : "(Ca c'est pour qui vous savez qui pense que je n'ai jamais rien codé et que je viendrais m'abaisser à discuter ici avec mon vrai pseudo).", En fait ta phrase me parait, maintenant, reconnaître au contraire que ChristopheS n'est pas ton vrai pseudo et que tu considères que ce serait t'abaisser de venir ici avec ton vrai pseudo... En tout cas rien que le fait de penser que venir ici c'est "s'abaisser" ça correspond bien au souvenir que j'ai de ton "ami". Je dirais si ce que je crois comprendre de cette phrase s'avère exact et bien, pour moi, ça ne grandit pas du tout "ton vrai pseudo" et justement ça l'abaisse deux fois plus que si "ton vrai pseudo" venait ici ouvertement...


De même pour celle sur ce qui manque au processeur. Je me suis souvenu qu'un certain processeur que tu as cité ici avait semble t il pile ce que tu dis comme point fort :


https://www.gamopat-forum.com/t41296p360-amiga-st-vs-archimede

Je cite le passage que cela m'a rappelé

"Maintenant les avantages : 
- il est très doué pour les interruptions. Grace au sacrifice d'un registre qui sera utilisé pour l'adresse de retour (bien plus rapide mais moins souple quand il s'agit d'empiler des interruptions) et à la possibilité de swaper des registres en internes."


Et comme je ne sais pas ce que veut dire "avoir des instructions non interruptibles", j'ai fait une recherche google et étrangement on tombe pile sur le même processeur :







Je m'étonne donc encore de tomber très proche du sujet de prédilection du pseudo de ton "ami" 

@Babsimov l'AGA c'est du raté.
Compte sur les cartes accélératrices pour corriger les niaiseries de Commodore.

Et qui t'as dit que l'AGA c'était le top ? Tout le monde sait que l'AGA était loin d'être au niveau, la faute à la direction qui n'a mis les moyens pour sortir en 1990 un chipset digne de l'OCS en son temps. L'AGA était une solution "court terme" suite à la bévue de l'ECS. Ils ont même essayé de vendre des versions du 4000/1200  (qui ne s'appelaient pas comme ça) avec seulement l'ECS en 1991/92... mais aucune filiale de Commodore n'a commandé ces machines et c'est pour ça que l'AGA a été remis dans le 4000/1200, en zappant le DSP.  

Chipset d'origine à chier (j'adopte la dlfrsilver attitude, le modo semble trouver ça cool) vive les cartes accélératrices dont un tiers de la puissance va servir à compenser la crotte chipsetique au coeur des machines Amiga.

L'OCS (Original Chipset) a été salué à sa sortie comme un bijou technologique, ne t'en déplaise. 

Il été expliqué ici comme son architecture exploitait habillement les "faiblesses" du 68000.

L'architecture de l'Amiga était loin d'être "moisie" comme tu te plait à le dire.

EDIT : Je viens de me souvenir qu'en plus je t'avais déjà dit que l'architecture avec le processeur qui fait tout était la plus archaïque. La preuve, les PC actuelles ont tous des coprocesseurs partout, comme l'Amiga en son temps... surement un hasard puisque selon toi les coprocesseurs c'est "moisi"... 
Surtout c'est étrange de ta part vu comme dans le sujet Falcon tu nous l'as tant vanté l'avantage du coprocesseur DSP du Falcon... Pas très logique dans ton argumentation tout ça... Surtout que finalement tu n'as pas eu de Falcon, pas de ST (enfin parfois je finis par en douter), mais par contre un PC avec une GUS (que tu mets bien en avant, alors que c'est pile le même principe que Paula... 0% de processeur) 

https://www.gamopat-forum.com/t82337p60-guerre-st-amiga-fight#2177278

Je cite (il y a même une partie sur l'AGA) :

"babsimov, 

pour les démos, Seb a répondu bien mieux que je n'aurai pu le faire (merci à lui pour cette explication détaillée et très interessante). 

Pour l'explication que tu demandes, je suis obligé de passer par des généralités barbantes pour que tu puisses comprendre: 

D'abord les cycles processeurs : 

Le cycle représente l'unité de base temporelle d'un processeur. A chaque cycle, un signal est envoyé par une horloge (un quartz, un oscillateur, etc..) au 68000 via une broche dédiée (l'une des "pattes" du microprocesseur). On dit qu'il est "cadencé". A chacun de ces "tops", des actions très élémentaires sont effectuées par le 68000. Plus la vitesse à laquelle sont envoyés ces signaux est élevée, plus le processeur tourne vite. Mais il y a une limite au-delà de laquelle le processeur ne pourra pas aller. ça peut être parce que les élements internes qui le composent ne pourront pas changer d'état assez rapidement. Ou parce que le processeur se mettra à trop chauffer. En effet à chaque fois que des "actions élementaires" sont effectuées, il y a circulation de courant dans le processeur et donc création de chaleur. Plus le processeur va vite et plus il consomme et plus il chauffe. 

Les 68000 qui se trouvent dans un mig ou un ST sont les mêmes. Mais celui du ST est cadencé à 8 Mhz alors que celui du mig à 7,14. C'est l'horloge qui le controle qui diffère. 

La RAM : 

La RAM d'un ordinateur est divisé en "cases". Dans une architecture 8 bits, chaque case fait un octet (8 bits). Dans une architecture 16 bits, chacune fait un mot (16 bits). Concretement, cela signifie qu'il y a 8 ou 16 fils qui véhiculent la donnée à lire ou à ecrire (en schématisant). Chaque fil correspondant à un bit, il transmet la valeur 0 ou 1. On appelle cet ensemble de fils le bus de données. 
Cela ne suffit pas pour accéder à la RAM : c'est bien beau d'être capable de véhiculer une donnée. Mais il faut également pouvoir indiquer depuis ou vers quelle case le faire. Chacune des cases qui composent la RAM reçoit donc un numéro. Donc en plus du bus de données, on utilise un autre ensemble de fils qui permet d'indiquer le numéro de la case à laquelle on souhaite accéder. Ce numéro de case s'appelle "l'adresse". Ce deuxième ensemble de fils s'appelle donc le bus d'adresse ou d'adressage. Ce système permet d'accéder à n'importe quel case sans contrainte (En fait il peut y en avoir mais on va ignorer çat. De toute façon ça ne concerne pas le ST ou le MIG). C'est à cause de catte faculté que la mémoire est appelée RAM (Random Access Memory). On peut très bien imaginer une mémoire à laquelle on accède à une case en lisant toutes celles qui précèdent de façon séquentielle. ça serait bien de la mémoire vive, mais pas de la RAM. 

Maintenant les RAM ont une vitesse : quand tu veux lire ou écrire une donnée, ça n'est pas immédiat. ça prend un certain temps. Par exemple, 125 nanosecondes. Soit 0,000 000 125 secondes. Donc il sera possible d'accéder à la RAM 8 000 000 de fois par seconde. On parlera dans ce cas de RAM à 125 nanosecondes ou 8 Mhz. On y reviendra. 

Revenons un peu au 68000, représenté par le schéma ci-dessous : 


Agrandir cette image


Si tu observes ce schema, on peut y voir : 

16 broches D0 à D15 : c'est le bus de données qui est bien sur 16 bits. 
23 broches A1 à A23 : c'est le bus d'adressage qui est sur 23 bits. Le 68000 peut donc gérer une RAM de 2 puissance 23 = 8 388 608 mots. Le double si on parle en octet. Ce qui fait 16 Mo. 
2 broches LDS/UDS : elle permettent d'indiquer si le 68000 doit accéder à l'octet qui se trouve dans les broches D0 à D7 (LDS=1, UDS=0), D8 à D15 (LDS=0, UDS=1) ou D0 à D15 pour traiter un mot (LDS=0, UDS=0). Ce système permet au 68000 accéder à un octet seul. Comme un bon vieux 8 bits. Ce n'est pas le cas de tous les processeurs 16 bits. 
1 broche R/W : elle indique si le processeur veut faire une lecture ou une ecriture (Read/Write). 
1 broche CLK : C'est la broche qui reçoit le signal d'horloge (les "tops" donc je parlais au début. CLK = clock. 

Sur la RAM, on retrouve aussi un bus de données, un bus d'adresses et un signal R/W. Si on les relit aux bus du 68000, ce dernier pourra travailler avec la ram. Si elle est assez rapide, il s'exprimera pleinement sans jamais subir de ralentissement. Simple et efficace. 

Mais insuffisant ! Cette RAM ne peut être utilisée que par le 68000 ! Or, pour pouvoir afficher une image contenu dans cette même ram, elle doit pouvoir être accessible par le shifter (ST) ou Denise (Amiga). 

Comment faire ? Et bien on ne va pas relier le 68000 directement à la RAM : on va intercaler entre les 2 un controleur mémoire (MMU dans le ST et Agnus dans le mig). Ce dernier sera d'un coté relié à la RAM et de l'autre à Denise ou au shifter. Un aiguillage qui va changer de coté 7,14 millions de fois par seconde pour le mig ou 4 millions de fois par seconde pour le ST. Donc à chaque fois que cet aiguillage se trouve dans une position, il y a le temps de faire un accès pour le mig ou 2 pour le ST. 
La vitesse à laquelle correspond ce basculement n'est pas un hasard : ça correspond à un cycle processeur pour le mig et 2 cycles pour le ST. Dans les 2 cas, les concepteurs auront prévu une RAM assez rapide pour permettre cet accès dans ce laps de temps. 

L'accès à la RAM est donc ralenti. Mais ce n'est pas grave ! Car le 68000 ne peut absolument pas accéder à la RAM tous les cycles : les instructions les plus rapides prennent 4 cycles. Pas de problème donc. 

Vraiment pas ? Mais si une instruction prend 5 cycles, quand elle sera terminée et que le 68000 aura besoin de lire la prochaine, l'aiguillage sera du mauvais coté et le 68000 devra attendre un cycle de plus ! Et oui ! Sauf que... Aucune instruction ne prend 5 cycles sur le 68000. On pourrait faire le même raisonnement avec un instruction à 7 cycles. Mais on va arreter là : toutes les instruction du 68000 prennent un nombre de cycles qui est un multiple de 2. Il n'y aura jamais de ralentissement. 

C'est ce que se sont dit les concepteurs du mig : puisque le 68000 fonctionne comme ça, on peut se permettre de réserver un accès mémoire sur 2 au chipset. 

Les concepteurs du ST se sont plutot concentrés sur la durée minimum de 4 cycles. la plupart du temps cela revient au même. Sauf que lorsqu'une instruction prend 6 cycles, le 68000 du ST sera obligé d'en attendre 2 de plus pour pouvoir lire l'instruction suivante. Idem pour une instruction qui prend 10 cycles. Le nombre réel sera toujours arrondi au multiple de 4 supérieur. 
Soyons clair : ça n'est absolument pas aussi grave qu'il n'y parait : la majorité des instructions du 68000 prennent déjà un nombre de cycles multiple de 4. 
Simplement, quand Shiraz Shivji expliquait que le bus du ST était plus performant que celui du mig, il mentait à toute la communauté ST... 

Revenons sur le mig. Est-ce aussi simple ? Est-ce que le mig n'est vraiment jamais ralenti ? Voyons ce qui se passe dans un mig avec un écran basse résolution en 16 couleurs : 
(je schématise beaucoup et je triche sur l'ordre. mais ça ne change rien au principe) 

Cycle 1  : Lecture des données du bitplan 1 (16 bits) 
Cycle 2  : Libre pour le 68000 
Cycle 3  : Lecture des données du bitplan 2 (16 bits) 
Cycle 4  : Libre pour le 68000 
Cycle 5  : Lecture des données du bitplan 3 (16 bits) 
Cycle 6  : Libre pour le 68000 
Cycle 7  : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 premiers pixels 
Cycle 8  : Libre pour le 68000 
Cycle 9  : Lecture des données du bitplan 1 (16 bits) 
Cycle 10 : Libre pour le 68000 
Cycle 11 : Lecture des données du bitplan 2 (16 bits) 
Cycle 12 : Libre pour le 68000 
Cycle 13 : Lecture des données du bitplan 3 (16 bits) 
Cycle 14 : Libre pour le 68000 
Cycle 15 : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 pixels suivants 

Et ainsi de suite... 

On se rend compte d'une chose : pendant l'affichage, tous les cycles réservés à Denise sont utilisés : Comment faire pour afficher 32 couleurs (5 bitplans) ou 64 (6 bitplans) ? 
Et bien c'est simple : on va utiliser certains des cycles initialement réservés au 68000. Pour 32 couleurs, il nous faut un 5eme bitplan : on va lire ses données pendant les cycles 6 et 14 dans l'exemple ci-dessous. Si le 68000 cherche à accéder à la mémoire pendant l'un de ces cycles, il devra attendre 2 cycles. 
Pour un affichage en 6 bitplans, ce sont les cycles 2 et 10 qui vont être pris. Pourquoi 2 et 10 et non pas 4 et 12 ? Pour s'assurer qu'il y avait toujours un cycle libre entre les 2 cycles perdus. Ceci afin de s'assurer que la latence imposée au 68000 ne dépasse jamais 2 cycles. 

Partant de ce constat, les concepteurs se sont fixés 2 contraintes : 
        - Les cycles ne devront être "volés" que pendant l'affichage. Ainsi, en 320x200x32 couleurs, il y aura 20x200 = 4 000 cycles perdus par frame. Et encore, c'est un maximum : le 68000 ne va pas tomber sur ces cycles à chaque fois. 
        - Ce "vol" de cycles ne devra s'effectuer que si besoin : pas question de laisser ce système activé si on affiche un ecran en 16 couleurs ou moins. 
Il a donc fallu passer d'un controleur mémoire qui se contentait de basculer entre denise et le 68000 à chaque cycles à un controleur capable d'adapter ses basculements au besoin. 
On est passé d'un système statique à un système dynamique. Le ST ne dépassant pas 16 couleurs, il peut se contenter d'un système statique. 

Et ça ne s'arrete pas là ! Et oui : dans le mig, il y a des copro qui peuvent avoir besoin d'accéder à la mémoire. Et le controleur doit pouvoir leur donner acces à la demande : il ne sait pas d'avance quels cycles réserver. Par exemple, il ne sait quand Paula aura besoin de lire un sample à l'avance : il doit lui envoyer quand il y en a besoin (en tout cas c'est le système qui a été choisi dans ce cas, car c'est le plus souple). 
Et il peut même y avoir des demandes d'accès simultanés de plusieurs copro ! Il faudra déterminer lequel doit être mis en attente. 

On n'est plus dans un simple controleur mémoire, c'est un circuit qui doit controler et prioriser toutes les demandes d'accès à la chip ram. Ces demandes peuvent parvenir de plusieurs sources : il y en a 25. Ce sont les fameux 25 canaux DMA du mig... 

Et les concepteurs ont fait du bon boulot : Par exemple, le fait de pouvoir envoyer à Paula un sample à la demande et non de façon régulière et imposée est ce qui permet à Paula de faire des variations de tonalité. C'est ce qui permet au mig de reproduire des mod avec une meilleure qualité que ses concurrents tout en consommant moins de cpu. 
Autre exemple : lorsque le blitter fait une opération et que le 68000 souhaite accéder à la chip-ram, le controleur peut interrompre le blitter juste le temps d'un cycle pour permettre au 68000 de ne pas rester bloqué. D'autant qu'avec de la fast-ram, le 68000 travaille en même temps que le blitter : il aurait été dommage de bloquer son traitement juste à cause d'un accès à la chip... 
Et ça peut être primordiale  par exemple si une interruption est déclenchée : sans ce système, le 68000 ne pourrait pas y répondre (s'il n'y avait pas de fast-ram). C'est ce qui arrive avec le STE : si on utilise le blitter pour déplacer un gros blocs de mémoire, le 68000 étant bloqué, il sera par exemple impossible de faire un changement de palette pour un raster. D'autant que lui n'a pas de fast-ram. 
Atari, pour contourner le problème, avait la solution : il préconisaient de découper le travail du blitter pour ne déplacer qu'un tout petit bloc de données à la fois. Après chaque travail, le 68000 doit redéclencher le blitter. Ce qui lui permet de répondre à une interruption entre 2 travaux du blitter. 
Je te laisse méditer sur l'élégance de la conception de notre "console à disquette" comparé à celle de "l'ordinateur hyper bien conçu"... 

Pour info : dans l'ordre de priorité des canaux DMA, celui réservé au disque (D7 ou HD) est le plus prioritaire. Celui dédié au sprites est le moins prioritaire. A tel point qu'on peut, dans certains cas, perdre l'usage de 1 ou 2 sprites : c'est le seul cas ou un canal DMA n'est plus disponible. 
Le chargement de données était primordiale pour les concepteurs alors que les sprites étaient l'élément le moins important : bizarre pour une machine conçue en tant que console... 

Je pense que tu commences à avoir une bonne vision sur cet histoire de cycles et d'accès à la chip-ram. 
En tout cas je ne peux pas faire plus clair... Ni plus barbant !   



Point suivant : qu'est-ce qui change avec l'AGA ? 

Avec l'AGA, la chip-ram passe à une architecture 32 bits. En gros cela veut dire que le bus de données utilise 32 "fils" et non plus 16 pour véhiculer les données à lire ou écrire dans la ram. Donc les données peuvent être lues 2 fois plus vite. En plus la RAM dispose d'un mode spécial qui permet de faire des lectures doubles en rafale. Et Lisa exploite ce mode, ce qui lui permet de lire les données 64 bits à la fois. Donc 4 fois plus vite qu'avec l'OCS/ECS. 
Concrètement, cette fois il n'y a plus besoin de voler des cycles au 68000 dès qu'on dépasse 4 plans en basse résolution. En 256 couleurs, on double la quantité de données par rapport à 16. Comme on lit 4 fois plus vite, on peut afficher ce genre de résolution en n'utilisant que la moitié des cycles réservés à l'affichage. En haute résolution 256 couleurs, on double encore : on atteint le max avant d'être obligé de "voler" des cycles au cpu. Donc un Affichage en 704x288x256 couleurs (ou 704x756x256 en entrelacé) ne provoque aucun ralentissement du cpu avec l'AGA. 

ça se sont les bonnes nouvelles. Maintenant les mauvaises : 

La chip-ram n'est pas accélérée : pour garder la compatibilité sans devoir refaire tout le chipset, Commodore a gardé la fréquence de 7 Mhz. C'est LE gros défaut de l'AGA. 
Et c'est pour cela qu'un A1200 va deux fois plus vite dès qu'on y met de la fast-ram. le 68020 tourne 2 fois plus vite que le 68000 et met moins de cycles (2 fois moins en général) a executer une instruction que le 68000. Pour qu'il soit aussi à l'aise que le 68000 dans l'OCS, il aurait donc fallu que la chip-ram aille 4 fois plus vite. Le passage en 32 bits lui permet de multiplier par 2 sa vitesse et ce n'est pas assez. 

S'ils avaient permit à tout le chipset de pouvoir basculer à 14 Mhz (quitte a pouvoir revenir à 7 Mhz pour la compatibilité), tout aurait été amélioré. Le blitter aurait été 2 fois plus rapide et le copper aussi. Le 68020 aurait atteint la vitesse max sans mettre de fast-ram. etc... 
Ils ont choisi la facilité : ils ont remplacé Denise par Lisa mais ont gardé le reste tel quel. Donc le blitter est le même et le copper aussi. 

Quand à Paula, elle gère le son et les accès disque : elle ne gene pas le 68020. D'autant que la lecture d'un sample n'a jamais demandé beaucoup d'accès mémoire sur le mig. 

Il y a eu beaucoup de spéculations sur ce qu'aurait du être le A1200 : chunky pixel, DSP, j'en passe et des meilleurs. 

Je ne suis pas d'accord avec tout ça : ce qu'il fallait, dans l'idéal, c'est une fréquence doublée pour le chipset et un passage en 32 bits pour tous les copro. Le blitter aurait été 4 fois plus performant ()alors qu'en 256 couleurs on n'a besoin de ne déplacer "que" le double de données). Idem pour le copper (sa résolution aurait de 2 pixels au lieu de 8). Idem pour Paula (ça aurait permit 8 canaux en 16 bits ou 16 en 8 bits). Il aurait également fallu que l'entrée de gamme pour le processeur soit au moins un 68020 à 28 Mhz. 

Un A1200 avec tout ça (Meme pour un prix plus élevé : le A1200 était vendu moins cher que le A500 à sa sortie...) aurait eu beaucoup plus de chance."

(C'est tellement beau de faire du C2P et du mixage temps réel vers les 4 ridicules canaux de Paula).
En fait l'Amiga c'était la même daube que le PC Windows tant critiqué : une architecture moisie où les performances du CPU sont bouffées pour des trucs idiots.

Là je suppose que tu parles de la génération AGA, parce que le C2P c'est pas trop l'époque de l'OCS. A noter qu'il y a des routines C2P au blitter et même au copper si je me souviens bien, ce qui évitait d'avoir besoin de carte accélératrices (je dis ça de mémoire). Certes ce n'était pas en résolution 1x1 pour que ce soit jouable.

Pourquoi mixage temps réel pour Paula ? Paula c'est 0% de processeur, même en mode 14 bits. Bien sur que Paula n'aurait pas du être là dans l'AGA ou, au minimum, épaulée d'un DSP.

Par contre si les 4 voix de Paula étaient loin d'être ridicules en 1985. Je te l'avais déjà expliqué, même les stations de travail n'avaient pas ça en standard et leur carte son optionnelle c'était 2 voix 8 bits. J'avais donné le lien vers le débat sur le son, mais j'ai l'impression que tu n'as même pas été le lire (il est pourtant très intéressant et avec tes connaissances pointus tu pourrais peut être apporter des précisions ou corrections ?

beeAware

youki

Quand au multitache preemptif , tu peux le faire sur n'importe quel processeur. Apres c'est juste plus ou moins chiant a faire.

Ben non, sur le 6502 il semble que même de nos jours ça n'existe pas, c'est ce qu'expliquait Stapha92. Ce serait possible mais ça ramerait énormément.

...

Grace à ça, le simple fait de stocker/restaurer tous les registres processeur va permettre de gérer une pile différente pour chaque process. 
Et le 6502 ? Et bien il pose un problème : le registre de pile ne contient qu'un octet. Or les adresse du 6502, comme celles du Z80, sont stockées sur 16 bits, soit 2 octets. Comment fait-il ? C'est simple : le 6502 considère toujours que le premier octet de l'adresse de la pile vaut 1. Cela revient à dire que pour avoir l'adresse réelle de la pile, il faut toujours ajouter la valeur 256 à celle qui est stockée. Donc la pile d'un 6502 sera toujours située entre les adresse 256 et 511 pour des valeurs de son registre qui iront de 0 à 255. 
Du coup, il n'y a aucun moyen de forcer le 6502 à stocker sa pile ailleurs. 

En résumé, la pile d'un Z80 ou d'un 68000 est relocalisable. Pas celle du 6502. 
Donc, pour faire du multitache avec le 6502, il faudra sauver/restaurer 256 octets (1024 accès mémoire...) à chaque basculement de tache. Ce qui va donner un os qui rame. Le seul moyen de s'en sortir est d'utiliser un système de banque mémoire. Mais il faut un hardware dédié. 

Non, ce n'est pas tout à fait exact : la pile du 6502, et plus exactement la stack pointer, est bien relocalisable mais seulement sur 256 bytes (cf. instructions TXS et TSX du CPU). Ce qui signifie qu'il est possible de faire du multitasking sans avoir à sauvegarder/restaurer la pile à chaque basculement de tâche : mais les piles auront une taille limitée (par exemple, 8 tâches max avec 32bytes/pile).

Merci de ces précisions. Tu dois savoir que je ne suis nullement programmeur ou connaisseur en hardware. On a vu dans une vidéo un OS multitâche sur 6502. A l'époque de la réponse que je citais, j'avais compris que cela n'était pas encore fait. 

Chapeau pour les développeurs en tout cas.

Turrican 3 aga ou rien... 

Turrican j'accrochais pas. Non, je préférerais un jeu style Battle Squadron mais poussant l'AGA à fond.

L'AGA a t'il un fond d'ailleurs ? A première vue, non... 

Tout ce qui pourra être poussé à fond au mieux de nos jours sur Amiga c'est AMOS, et on en est encore très loin du fond (d'AMOS). 

Suis-je compréhensible dans mon propos ? 

Cela me ferait presque acheter un ST et cela me fait vraiment mal d'écrire cela. Encore un problème de fond...

L'AGA doit bien avoir des possibilités jusqu'à nos jours inexploitées en jeu ? C'est certain qu'on ne peut pas espérer autant d'exploit sur AGA qu'il y en eut sur OCS cependant.

Je ne comprends pas bien la remarque pour AMOS ?

Ta dernière phrase est façon élégante de dire qu'en faite un ST ne "vaut rien" face à un Amiga  

Pas vraiment, sous cette tournure " élégante ", j'informe que le simple fait de devoir acheter un atari ST(E) juste pour avoir des trucs intéressants pourrait potentiellement me faire mal à l'arrière train. Souci de fond en somme. 

Oui, j'avais compris, mais je pouvais pas te laisser sous-entendre ça 

J'ai donc supposé qu'un ST devait coûter moins cher qu'un Amiga de nos jours, ça allait bien avec fond aussi 

Et puis c'était aussi un moyen de te remonter le morale et t'éviter de "sombrer" dans l'univers ST... (cela signifie Star Trek bien sur, loin de moi l'idée de dénigrer une quelconque machine... ben quoi "mauvaise foi".... pas du tout) 

[ChistopheS]

Je n'ai lu que quelques lignes et oui je suis Zarchos et je vous emmerde.
Forum de pro Amiga nases à pisser de rire.

[Tryphon]

T'es méchamment atteint quand même...

[Invité]

T'es méchamment atteint quand même...

je sens qu'il va être surtout atteint par une crise de GX4000