Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#26 Le 09/10/2014, à 06:37

The Uploader

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

lol Euh non. L'Atari ST* était loin derrière niveau matos et logiciels et jeux.


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#27 Le 09/10/2014, à 07:40

tiramiseb

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Ou pas.

Hors ligne

#28 Le 09/10/2014, à 07:56

Compte supprimé

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

ares a écrit :


Je me demande d'ailleurs si "l'Amiga" n'est pas une formidable copie issue des travaux du PARC Xerox smile

Je ne sais pas, compare les dates des projets ?

Dans l'exemple ASM que tu donnes... on ne fait pas une soustraction mais une décrémentation de registre :
* on gagne un octet dans le code
* la décrémentation ; c'est 1 cycle horloge, une soustraction c'est plus.

Sympa les démos... j'ai un ami (Amiga-iste) qui en a des "tonnes"... certaines sont des merveilles artistiques.
Hum ! on parle de quoi ?!? c'était quoi le sujet ?!?
Bon je vous laisse, faut que je passe chez l'Amiga-iste fou me faire une soirée rétrospective demoscene ~~~~~~~>[]

J'adore !
C'est vrai pour la décrémentation, mais la dernière fois que je me suis plongé dans l'assembleur 68k remonte à l'an 2000 ou 2001 …
Sans pratiquer depuis, j'ai gardé le principe de la boucle, avec le réflexe de mettre un subq #1,d0 parce que le quick pouvait coder -8 à +7 à l'intérieur de l'instruction sans rallonger le code en effet, mais je devrais replonger dans tout ça si j'avais le temps … si j'avais le temps … ou si je prenais le temps … autant me farcir les 4600 pages du langage machine x86_64 … et de voir ce qu'on peut faire avec un PC … puisque je n'ai plus de machine matérielle sous 68k, à part la TI92+, mais j'aurais l'impression de perdre du temps …

PS : Je ne sais même pas si le programme que j'ai donné, tapé en mode texte sans programme d'assemblage avec les couleurs, les vérifications de syntaxe, le classeur de 500 pages du Cybex que j'avais autrefois à proximité, tourne sans faute de syntaxe, c'est juste un principe de ce qui ressemble à l'assembleur, qui reste très humain, afin de comparer au LM en hexadécimal par exemple, mais qui pourrait se lire en binaire … et qui ne sont souvent représentés que par des nombres pour faire sentir à Elzen la différence entre ces deux équivalents : l'assembleur coté humain et le Langage Machine coté processeur … sans trop diverger du sujet initial wink → regarder les magnifiques démonstrations écrites en assembleur ! ←

Bonjour ares, qui semble avoir plus utilisé le 68k que moi avec mon Amiga chez moi, et le module d'informatique industrielle dans ma formation EEA …
Tu sembles comparer un processeur de 1996 lapx86 (qu'est-ce ?) avec un MC68000 de 1979 …
Un 68060 de 1994 serait plus équitable smile

Maintenant, je ne comprends pas, bien que tu sembles connaitre le 68k alors que tu ne connais pas l'Amiga, que ta comparaison s'arrête au processeur ?
Le processeur fournissent les MIPS, mais sur les PC à l'époque, il me semble que le processeur à base intel doit tout faire, là ou l'Amiga a distribué les taches élémentaires à des processeurs conçus sur mesure … libérant le processeur Motorola, qui fonctionne un peu comme chef d'orchestre …

ares a écrit :

Pour les fondus de l'asm x86 y'a Yasm qui permet de faire des "trucs" sympas.
Yasm est très complet et prend en charge les spécificités des CPUs AMD, Intel, etc

Comme le faisaient les Assembleurs de motorola … smile Mais écrire un code optimisé 68030 ne tournerait pas sur 68000 … à moins de faire du code à rallonge … version de base 68000 et de récrire chaque routines sensible en fonction de processeur pour n'avoir qu'un programme, et d'autres programmes optimisés pour chaque processeurs donnaient des versions différentes pour 68000 68020 68030 68040 …
Un peu comme i386 et x86_64 …

ares a écrit :

Là ou nous ne sommes pas d'accord L_d_v_c@ ... c'est de comparer l'AmigaOS avec Windows NT4, car c'est pas flatteur pour l'Amiga.
J'aurais plutôt choisi "OS2/Warp" un bon OS multitâche qui m'a enfin décidé dans mon choix à l'époque big_smile

Si la comparaison est flottante flattante smile je trouve pourtant, NT4 est ce qui fonctionnait le mieux sur PC à l'époque (vers 2000) parmi mes copains présents à l'université ! smile

L'Amiga 1200 (de 1992) avec une blizzard IV (68030+68882 + 16 Mio EDO) à 50 MHz (de 1995) tournait à la même vitesse que le PC sous NT4 à 200 MHz (de 2000) … avec la même latence d'utilisation.

Quoi de plus flatteur pour l'Amiga à base Motorola ?

Un peu comme le nouvel Amiga acheté en 2004 :

L_d_v_c@ a écrit :

Le PowerPC 603 équipait les nouveaux Amiga de 2004.
Nos tests succincts sur le PowerPC 603 à 900 MHz (sur Yellow Dog Linux) le ramenait à un Intel à 1400 MHz virtuels (sur Debian). Tests aux décimales de Pi programmés en C.
En fait le PC sous Debian à 1600 MHz allait à 114% de l'Amiga sous Yellow Dog Linux avec le processeur PowerPC 603 à 900 MHz.

C'est connu depuis longtemps que PC (Intel et Amd) aiment afficher des MHz et des GHz qui ne reflètent pas les puissances de calculs.
Les Amiga ont toujours été plus performants de leur époque

Et pourtant l'Amiga de 2004 n'était plus conçu sur le principe de ce qui fait un Amiga d'origine : une osmose technologique informatique.
En 2004, la comparaison était le reflet du PPC comparé à Intel.

En bref, un PPC603 à 1GHz ferait le même travail qu'un Intel à 1555 MHz. Mais la course des CPU est indicative, mais quand tu te sers vraiment d'un ordinateur, c'est l'architecture interne qui compte.

Apparemment, la mémoire partagée multi-accès des premiers Amiga (chaque composant : son, vidéo, port série et parallèle, contrôleur de disques, avaient accès direct à la mémoire sans passer par le CPU) a plus ou moins été copié par intel …
→Mais sur un PC classique, il ne me semble pas que la mémoire soit physiquement double-access ?

http://wiki.amigaos.net/wiki/Programming_in_the_Amiga_Environment#Dynamic_memory_architecture a écrit :

Two Kinds of Memory
To keep the Classic Amiga running efficiently, the Classic Amiga has two memory buses and two kinds of memory. Chip memory is memory that both the CPU and custom chips can access. Fast memory is memory that only the CPU (and certain expansion cards) can access. Since Chip memory is shared, CPU access may be slowed down if the custom chips are doing heavy-duty processing. CPU access to Fast memory is never slowed down by contention with the custom chips.

The distinction between Chip memory and Fast memory is very important for Classic Amiga programmers to keep in mind because any data accessed directly by the custom chips such as video display data, audio data or sprite data must be in Chip memory.

Mais pourquoi pas comparer une grosse configuration PC i7 et un processeur Cell équipant les PS3 tant qu'on y est ? tongue
le processeur Cell utilisé par la console, qui dispose d'une puissance de calcul vectoriel de 230.4 Gigaflops (février 2005)
En 2013 un Ordinateur personnel peut disposer d'une puissance d'environ 200 gigaFLOPS avec un microprocesseur de puissance comparable aux superordinateurs de 1995 comme l'Intel Core i7-3770 (pour seulement 269€ ! ha ha ha)

Je suis sur PC parce que le porte feuille ne le permet pas encore d'avoir mon ordinateur avec un processeur TiILE-Gx 100
Processeur TiILE-Gx 100 à environs 1000 $ début 2011.
Précisions importantes sur le TILE-Gx à 100 cœurs tournant à 1,5 GHz.
Gravure 40nm. 10W à 55W pour les applications typiques.
(55 watts en pleine charge sur les 100 cœurs ? )
Array of 16 to 100 general purpose processor cores (tiles)
64-bit VLIW processors with 64-bit instruction bundle
Three-deep pipeline with up to 3 instructions per cycle
Massive 32 Mbytes of on-chip cache in the TILE-Gx100
Up to 750 billion 32-bit operations per second (BOPS)
Up to 200 Tbps of on-chip mesh interconnect
Over 500 Gbps memory bandwidth with two or four 64-bit DDR3 controllers

Mais je l'aurai cette ordinateur si le Studio musical fonctionne wink

Tiens, je vais éteindre l'ordinateur et reprendre une activité électronique …

Dernière modification par Compte supprimé (Le 09/10/2014, à 08:04)

#29 Le 09/10/2014, à 08:15

The Uploader

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

tiramiseb a écrit :

Ou pas.

Bien sûr que si. Renseigne toi.


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#30 Le 09/10/2014, à 08:18

tiramiseb

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

De toute façon je peux pas avoir tort, j'avais un Atari STe. Na !


... plus sérieusement, j'en ai rien à foutre. Ces deux machines étaient à peu près équivalentes, plus ou moins adaptées à certains usages. Mais j'aime nourrir le troll smile

Hors ligne

#31 Le 09/10/2014, à 08:27

The Uploader

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

à peu près équivalentes ?
HA !

Compare la version ST de Turrican 2 à celle de l'Amiga par exemple. Rien à voir.

Turrican 3 ne tournera même pas sur un ST. Un ST de la dernière génération à la limite....

Quant au son, le ST faisait bip-bip comparé à l'Amiga. Sérieusement...

Dernière modification par The Uploader (Le 09/10/2014, à 08:27)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#32 Le 09/10/2014, à 08:29

tiramiseb

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Quant au son, le ST faisait bip-bip comparé à l'Amiga.

Et c'était quoi, les voix de synthèse dans Le Manoir de Mortevielle sur Atari ST ? Des bip-bip aussi ?
« Février 1951… Profession : détective privé. Le froid figeait Paris et mes affaires lorsque… Une lettre, un appel, des souvenirs d’une enfance encore proche. Que de jeux dans les pièces délabrées du manoir de Mortvielle. Julia, une vieille femme à présent… »
brrr, que de souvenirs...

Hors ligne

#33 Le 09/10/2014, à 08:49

The Uploader

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Euh c'est pareil sur la version Amiga... Et essaie de jouer un MOD (ou avoir juste de la vraie musique, ou des effets sonores dignes de ce nom en fait) sur Atari ST, tu vas rire...


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#34 Le 09/10/2014, à 08:56

tiramiseb

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Eh ouais, comme tu dis : « c'est pareil sur [...] Amiga ».

Et c'est rigolo que tu parles de musique, vu que l'Atari ST était très apprécié des musiciens grâce à ses ports MIDI intégrés...

Hors ligne

#35 Le 09/10/2014, à 09:07

The Uploader

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Ce n'est pas ce que j'ai dit.

J'ai dit que les voix digitalisées de Morteveille/Maupiti sont pareil sur les deux.

Mais que ce soit au niveau du nombre de couleurs, du son, etc... 99% du temps c'était bien inférieur sur Atari par rapport à l'Amiga.

Et oui l'Atari son seul intérêt c'était ses ports MIDI. Ca n'a pas empêché l'Amiga d'avoir des trackers et des musiques MOD (et formats dérivés) qui déchiraient bien son cul à l'Atari.

Dernière modification par The Uploader (Le 10/10/2014, à 05:49)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#36 Le 09/10/2014, à 12:03

Compte supprimé

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Un copain qui programmait en assembleur sur Atari Falcon 030 s'était intéressé à quelques démonstrations (écrites en assembleur) utilisant le Falcon 030.
Ça en mettait vraiment plein la vue wink

Quant aux logiciels de musique, je rappelle que les .mod étaient compatibles Amiga/Atari/PC smile et on retrouvait souvent les mêmes trackers sous Amiga et Atari.

Med, puis octamed, puis Octamed Sound Studio coté Amiga cependant par la suite,
Et Atari a vu Cubase 1.0 ! qui arriva plus tard sur PC …

Mais quand tu penses aux 4 canaux 8 bits (deux à gauche, deux à droite) de l'Amiga natif avec 4 volumes codés sur 6 bits, et que tu te dis oui, bien pour 1985, et qu'un patch en assembleur transforma tout ça en 2 canaux sur 14 bits à 56 kHz  <3 <3 <3 dans le logiciel Octamed Sound Studio  <3 <3 <3, sans rien modifier au hardware, à condition d'avoir un bon Amiga au départ, ou une petite carte accélératrice pour mixer 64 canaux en 16 bits, restitués en 14 bits demandait un peu de puissance processeur … Une blizzard IV 68030 + 68882 à 50 MHz suffisait, et au pire, il fallait exporter le projet car le son était limité à l'origine à 28 kHz avec les modes d'affichages par défaut en Pal (branché sur une simple télévision), et il fallait malheureusement changer de mode d'affichage pour avoir du son en 44,1 kHz, jusqu'à 56 kHz, avec les circuits d'origines  <3 <3 <3 … perdant l'affichage momentanément lors de la restitution sad ← ma première solution low cost
ou ne rien changer à l'affichage et acheter une carte son pcmcia … 44,1 kHz / 16 bits … ← ma deuxième solution après la carte accélératrice …
ou avoir un écran double pal, ou double ntsc laissant travailler le son avec le patch en 56 kHz / 16-14 bits.  <3 <3 <3

Amiga <3 <3 <3 smile

Voilà quoi …

Il m'a fallu du temps pour trouver mieux que l'Amiga, et arriver à me contenter d'un PC, mais il a fallu des années de progrès technique, et informatique coté PC, grâce à Linux que j'avais été voir à Bordeaux an 1994, mais sans intérêt à l'époque comparé à l'Amiga, et il m'a fallu aussi beaucoup de sous, débourser 525€ (une promotion) pour une carte son en Firewire …

Bref, l'Amiga était l'ordinateur performant parfois premier prix (A500, A600, A1200 …) pour tout le monde. 2 à 3 fois moins cher que le premier PC.
Merci Aminet et les gigaoctets de programmes … les dizaines de CD.  <3 <3 <3

PS : Pour information je numérisais ma voix ou les musiques avec un petit programme surement récupéré et tapé en lignes DATAS … (une façon de passer du langage machine à l'Amstrad depuis le Basic 1.0…) sur CPC 6128 avec soit la prise DIN 5 broches du lecteur de cassette, soit la prise du koystick, j'ai oublié. Ne m'y étant pas attardé. Forcément, je travaillais environs à quelques kilohertz en 1 bits, c'était très expérimentale, mais ça rendait bien déjà pour du 1 bit : on pouvait faire ça avec un ordinateur.

On aperçoit la prise du lecteur de cassette TAPE en haut à gauche au dessus de JOYSTICK : 1412851387.jpg

Mais très loin de la qualité des musiques classiques qui passaient sur la platine vinyle Philips, amplificateur HI-FI 2×15 watts et enceintes Dynamic Speaker DS65  (65 watts) avec une qualité de précision stéréophonique que je ne retrouve pas avec le numérique (même en 96 kHz), qui n'a permis que de supprimer le bruit de fond, et non, mes disques vinyles achetés neufs ne craquaient pas, je suis soigneux … mais ils soufflaient comme tous les disques vinyles qu'on écoute un peu trop fort.

Je ferais mieux d'écrire une autobiographie, puisque je commence à perdre la mémoire et que je ne me souviens plus quelle prise j'avais utilisée pour numériser en 1 bit sur Amstrad 6128 … sad

#37 Le 09/10/2014, à 22:49

ares

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

tiramiseb a écrit :

À cette époque il y'a Amiga...
- en dessous : rien
- toujours en dessous : ben... rien
[... bla bla bla ...]

Et au-dessus : Atari ST.

Excellent ! big_smile big_smile

L_d_v_c@ a écrit :

C'est vrai pour la décrémentation, mais la dernière fois que je me suis plongé dans l'assembleur 68k remonte à l'an 2000 ou 2001 …

C'est de mémoire, car les 680x0 d'aujourd'hui de type superscalaire effectue certainement l'opération en 1 cycle avec une valeur immédiate.
Le "truc" basique de l'époque pour gagner des "cycles horloge" smile

L_d_v_c@ a écrit :

Tu sembles comparer un processeur de 1996 lapx86 (qu'est-ce ?) avec un MC68000 de 1979 …
Un 68060 de 1994 serait plus équitable

J'ai simplement lu la documentation 68000 et 68020... et comme cela m'amusait... 386 & 486... je me suis arrêté au Pentium.
Au taf, j'ai moins le temps et je suis passé à la BD smile
lapx86 précise qu'il s'agit d'une famille de circuits intégrés développés par Intel. Il fallait un gestionnaire mémoire (MMU) contrôleur de Bus etc, "puce"
que le fondeur pouvait fournir pour obtenir un ordinateur smile.

Conclusion perso...
On est sur des CPU CISC, les similitudes sont  grandes. Les différences :
* les modes d'adressages mémoires i386 et surtout son mode 8086-virtuel.
* la possibilité d'utiliser 4 niveaux d'exécution. Je connais pas le 68060... mais il me semble que non.
* Le gros péché dans la famille Motorola c'est son FPU  : différence de vitesse avec son CPU.

Ce qui était très intéressant sur un 386 Intel c'était ces très nombreux modes d'adressages... tellement riche que sur certaine routine, il était plus rapide de laisser le CPU calculer une adresse mémoire pour la transformer en résultat d'une opération arithmétique.
Et j'ai commencé avec un 486... CPU qui remettait en cause certaines optimisations assembleur... la rupture... un bordel... comme un divorce...

Comme on s'amusait pas mal... j'avais fait un programme pour comparer les vitesses d'adressages entre Intel, AMD et Cyrix en mode protégé.
Cyrix était bien meilleur avec un gain de 22% et beaucoup moins cher qu'un Intel... fallait pas foutre grand chose au "taf" pour faire ce genre de connerie !
J'ai été "remercié" vue que la boite n'était pas "partenaire" de Cyrix big_smile

L_d_v_c@ a écrit :

Mais pourquoi pas comparer une grosse configuration PC i7 et un processeur Cell équipant les PS3 tant qu'on y est ?

D'accord... mais on ne peut comparer un i7 (CISC)  avec un Cell (RISC) et le Cell est prévu d'abord pour un usage spécifique.

Et puis le passé... c'est le passé, regardons devant nous. L'avenir est aux langages de haut niveau et au "out of order" et probablement au compilateur interne ; génération du binaire par le CPU 1 fois avant exécution multiples... Et puis de jeune con... je deviens un vieux con sans aucune « optimisation » big_smile

Mais en faisant un (petit) retour, j'avais rencontré un retraité de tf1 qui avait utilisé l'Amiga pour les titres ou texte qui étaient diffusés sur la chaîne (20h etc).

Der de der... avant de quitter ton très bon sujet L_d_v_c@ :
La Xerox Star en 1981(en)
– concept d’interface graphique
– icônes,
– dispositif de pointage pour ordinateur ou souris. Le PARC utilisera l’invention de Douglas Engelbart du Stanford Research Institute (1963),
– menu déroulant, copier & coller, glisser& déposer,
– premier traitement de texte WYSIWYG
– Smalltalk-80, programmation orientée objet
– impression laser,
– protocole réseau Ethernet.
Mais Xerox en 1980 c'est aussi :
première carte graphique couleur capable d’afficher une image et aussi de numériser un signal vidéo,
– premier logiciel de dessin en couleurs et aussi premier logiciel d’effets vidéo numériques,
– image 3D,
– encre numérique

@+

Hors ligne

#38 Le 10/10/2014, à 09:51

Compte supprimé

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Salut rapide ares, et les autres,

il me semble bien que les choses ont énormément changé depuis le dernier CISC pour PC fabriqué chez Intel : le 486.
Le choix s'est porté sur le RISC à partir du 586 à nos jours, afin d'avoir des processeurs pouvant atteindre de telle fréquences d'horloge, la plus grande fumisterie informatique ! tongue

Le i7 est bien un RISC, comme les derniers processeur sur PC (Intel/AMD) à partir des 586 inclus. Et tu as travaillé sur RISC à partir de ton Pentium, sans t'en rendre compte smile
Why does Intel hide internal RISC core in their processors?
Quand Linux corrige les «microcodes» des processeurs actuels, il ne fait que récrire des routines en RISC je pense (mais pas eu le temps de vérifier).
Bien sûr, on continue de donner à manger un code CISC aux Intel qui restent compatibles avec x86 et aux vrais CISC du 8086 au 80486.
--
En effet, ce n'est pas pour rien qu'il y avait des adressages immédiats sur CISC 68k, on gagnait en nombre de cycle.

Retour sur le 68030 : «Du fait que chaque instruction était simple, le décodage et l'exécution par le processeur devaient être très rapides, idéalement en un seul cycle, voire deux instructions par cycle, ce qui n'était pas le cas des instructions CISC. Sur les processeurs CISC les instructions étaient en général implémentées sous forme de micro-code dans le microprocesseur, chaque exécution de ce microcode prenait un cycle. Pour un Motorola 68000 par exemple, les instructions les plus rapides prenaient 4 cycles et les plus longues jusqu'à 160 cycles pour les divisions. Cela a changé avec les Motorola 68030, dont certaines instructions pouvaient ne prendre qu'un cycle.»

Parfois un seul cycle sur CISC 68k à partir du 68030, optimisations en vues, et pas des moindres wink
Le 68030 était comparé au 486SX … puisque le 68030 possédait une MMU mais pas de FPU.

Conclusion perso...
On est sur des CPU CISC, les similitudes sont  grandes. Les différences :
* les modes d'adressages mémoires i386 et surtout son mode 8086-virtuel.
* la possibilité d'utiliser 4 niveaux d'exécution. Je connais pas le 68060... mais il me semble que non.
* Le gros péché dans la famille Motorola c'est son FPU  : différence de vitesse avec son CPU. (je n'ai pas souvenir de ça, sauf possibilité de découpler les fréquence, mais les programmeurs utilisent des sémaphores il me semble, donc ça n'a aucun impact)

http://www.thefreelibrary.com/MOTOROLA+UNVEILS+32-BIT+68060+PRODUCT+LINE+OF+MICROPROCESSORS-a015136503 a écrit :

All integer arithmetic or logical instructions are able to perform an embedded load/store operation making the 68060 capable of simultaneously processing up to 250 million operations per second at 50-MHz.

Ok, seulement 250 MIPS à 50 MHz … comparés à 4,029.09 Mips avec Intel Core 2 Quad Q9550 (3995MHz) : cherchez l'erreur !
Un seul cœur du processeur Intel Core 2 Quad Q9550 (3995MHz) fournit 4 fois plus (édité) qu'un 68060 à 50 MHz !

Non mais vous avez vu les démonstrations qu'ils faisaient sur Amiga avec des 68EC020 mesurés à seulement 1,33 MIPS d'origine ???

Ensuite je ne comprends pas ça : « Le gros péché dans la famille Motorola c'est son FPU  : différence de vitesse avec son CPU.»
L'architecture (donc tout le multitache conçu en hardawre) n'était pilotée que par un seul quartz :

http://obligement.free.fr/articles/chipsetamiga.php a écrit :

Agnus gère les fréquences d'horloge (à partir de l'oscillateur central à 28,63636 MHz en NTSC et 28,37516 MHz en PAL), contrôle le rafraîchissement de la DRAM et la synchronisation vidéo. Sa fréquence propose est de 3,579545 MHz en NTSC et 3,546895 MHz en PAL. Elle gère aussi 25 canaux DMA (Direct Memory Access), ce qui permet au graphisme, à l'audio et aux entrées/sorties d'être utilisés avec un minimum d'intervention de la part du processeur. Enfin, c'est dans Agnus que figure deux coprocesseurs aidant la gestion graphique : le Copper et le Blitter.

Et lors des adjonctions passées des cartes accélératrice avec processeur ajouté (pouvant contenir MMU si 68030; 68040; 68060 …) et parfois un FPU si besoin (cas des 68881/68882 pour augmenter les puissances de calculs et libérer les 68EC020, 68020, 68030 puisque le FPU équipera en interne les 68040 et 68060 …)

… et bien comme marqué plus haut le CPU+FPU n'est pas le cœur de l'Amiga, pouvait faire leur travail de leur coté sans nuire à la synchronisation vidéo en passant par des sémaphores …

J'avoue que j'ai aperçu quelques vidéos en assembleur qui ne tournaient que sur Amiga d'origine, ou accéléré en fonction du Quartz principal … mais ces rares démonstrations n'utilisant pas les sémaphores, mais écrites en assembleur et tournant parfaitement sur les systèmes d'origine, je pense qu'un tel programmeur n'aurait pas eu de mal à intégrer le mécanisme des sémaphores.

Bon, tu as écris qu'il te semblait, ça va, j'ai détaillé pour la culture générale autour de ces vieux systèmes informatiques, et je laisse réfléchir à ça :

http://www.thefreelibrary.com/MOTOROLA+UNVEILS+32-BIT+68060+PRODUCT+LINE+OF+MICROPROCESSORS-a015136503 a écrit :

All integer arithmetic or logical instructions are able to perform an embedded load/store operation making the 68060 capable of simultaneously processing up to 250 million operations per second at 50-MHz.

Ok, seulement 250 MIPS à 50 MHz … comparés à 4,029.09 Mips avec Intel Core 2 Quad Q9550 (3995MHz) : cherchez l'erreur ! C'est Intel et le RISC l'erreur.
Un seul cœur du processeur Intel Core 2 Quad Q9550 (3995MHz) fournit autant qu'un 68060 CISC à 50 MHz !

Je comprends que beaucoup soit satisfait de la fluidité et de la réactivité apparente de GNU/Linux sur PC de nos jours puisqu'on a eu ça à partir des Amiga en 1985, que je n'ai connu qu'en 1993 avec mon A1200 qui n'était pas conçu pour faire tourner Doom, certes, mais qui ne faisait aucun bruit à part le lecteur de disquette, pas de ventilateur, et qui fit tout de même tourner Doom plus tard, mais je n'y voyais aucun intérêt, même encore aujourd'hui tous les trucs en 3D avec un ordinateur qui consomme presque 1 kW …

Mais je n'ai plus le temps d'aborder les cartes graphiques sur Amiga, puis je n'en ai jamais possédée.
Pas de souvenir des niveaux d'instructions, sur i486 il n'y avait que deux modes : un mode réel et un mode protégé avec 4 niveaux (je découvre) de privilèges.
En revanche sur 68040 on retrouve les deux modes : utilisateur et superviseur (pareil que 486 ? )
Je ne connais pas trop les i86.
Ça ? http://www-clips.imag.fr/projet-systeme/68040/040UM.pdf

B.5 EXCEPTION PROCESSING
The MC68EC040 provides five different stack frames for exception processing and allows
for a MC68040-specific stack frame. Refer to Section 8 Exception Processing for details
on exception processing.

Ça ?

3.1.1 User and Supervisor Root Pointer Registers
The SRP and URP registers each contain the physical address of the translation table’s
root, which the MMU uses for supervisor and user accesses, respectively. The URP points
to the translation table for the current user task. When a new task begins execution, the
operating system typically writes a new root pointer to the URP. A new translation table
address implies that the contents of the ATCs may no longer be valid. A PFLUSH
instruction should be executed to flush the ATCs before loading a new root pointer value,
if necessary. Figure 3-3 illustrates the format of the 32-bit URP and SRP registers. Bits 8–
0 of an address loaded into the URP or the SRP must be zero. Transfers of data to and
from these 32-bit registers are long-word transfers.

Dernière modification par Compte supprimé (Le 12/10/2014, à 05:03)

#39 Le 11/10/2014, à 21:15

ares

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

L_d_v_c@ a écrit :

Et tu as travaillé sur RISC à partir de ton Pentium, sans t'en rendre compte smile

Tu prends le cas du Pentium, mais il n'y a aucune « dissimulation » RISC en CISC... carun programmeur sur langage de haut de niveaux ; il en a RAB !

Entre le 68000 et Pentium il y'a eu principalement :
* normalisation des nombres flottant
* normalisation des protocoles caches mémoires (MESI)

Sauf erreur de ma part, le Pentium introduit deux principales nouveautés :
* prédiction de branchement,
* l’exécution dans le désordre (out‐of‐order execution)
* instructions vectorielles(MMX)

- La prédiction de branchement permet de "sortir" une instruction d'un pipeline lorsqu’un branchement conditionnel est rencontré.
On détermine si la condition sera « vraie », « plutôt vraie », « plutôt fausse », ou « fausse ».... en simplifiant.
On vérifie l'état de la condition pour sélectionner le  résultat disponible.

- Dans le cas de OoO ont fait appelle à des registre « fantômes » pour faire exécuter les instructions en parallèle en ayant une « anti-dependance » entre registre.
Cela implique que l'instruction CPU de départ est convertie en interne en une longue instruction (VLIW) typique d'un CPU RISC.
En plus il est possible de créer des "fenêtres" glissantes dans le cas cas de changement de contexte (Push etc) ou restauration (Pop)... principe des registres mémoire circulaire.

L'inconvénient aujourd'hui... mais pas à l'époque, est l'exécution de toute les instructions même les "inutiles" avec une consommation d'énergie en "plus".

Pour arriver a ses mécanismes cela  a impliqué :
* l'analyse de millions de lignes de codes
* de meilleurs compilateurs
* des programmeurs expérimentés et formés aux optimisations de codes.

L_d_v_c@ a écrit :

Parfois un seul cycle sur CISC 68k à partir du 68030, optimisations en vues, et pas des moindres wink
Le 68030 était comparé au 486SX … puisque le 68030 possédait une MMU mais pas de FPU.

Apple qui se fournissait chez Motorola n'arrivera jamais a construire son OS « révolutionnaire ».
Et ça pas été mieux en se fournissant chez IBM.

Intel avec son "386" permettait de construire un OS multitaches et multi-utilisateurs de façon « simple* » et robuste grâce à ses 4 niveaux
d'exécutions.
Malheureusement Microsoft a été un frein technologique... car sans doute n'avait pas la capacité a intégré ces technologies novatrices. 
Les « anciens » se souviennent sans doute des premières distributions Linux qui offraient déjà ces technologies.
QNX, OS temps réel,compatible POSIX avait été porté sur 386. Les démos sont très spectaculaires.
Les BSD étaient  aussi de la "fêtes" il me semble...

L_d_v_c@ a écrit :

Un seul cœur du processeur Intel Core 2 Quad Q9550 (3995MHz) fournit autant qu'un 68060 à 50 MHz !

Tu as d'autres sources sur les "perfos" en Mips car une simple recherche Google renvoi des valeurs nettement en dessous smile

À cette époque, l'Amiga ne se souciait pas de tout ça... et encore moins de corruption mémoire, adresses virtuelles, IEEE 754, protocole MESI etc.
Ce que tu expliques a propos de l'Amiga est impensable aujourd'hui avec les normes industrielles requises.

Bref, lAmiga a été « LA » référence dans le passé... on vit pas comme les Amish... enfin pour moi smile

@+

*)conter pas pour sur moi pour le faire, y'a un petit jeune qui le fait très bien... son blase, c'est Linus il me semble smile

Hors ligne

#40 Le 12/10/2014, à 06:15

Compte supprimé

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Bonjour, je rectifie juste une chose sur laquelle je me suis trompé (oui ça arrive) en calcul mental (je voulais juste faire sentir les performances-ratio) :
Ok, seulement 250 MIPS à 50 MHz … comparés à 4,029.09 Mips avec Intel Core 2 Quad Q9550 (3995MHz) : cherchez l'erreur !
Un seul cœur du processeur Intel Core 2 Quad Q9550 (3995MHz) fournit 4 fois plus (édité) qu'un 68060 à 50 MHz !

Dit autrement : un 68060 à 50 MHz accomplit le quart du travail d'un seul cœur d'un Intel Core 2 Quad Q9550 (3995MHz) , c'est à dire la moitié du travail d'un seul cœur d'un Intel Core 2 Quad Q9550 (1998 MHz) , c'est à dire le travail d'un seul cœur d'un Intel Core 2 Quad Q9550 (à 999 MHz).

Cette fois je ne me suis pas planté, merci de m'avoir repris ares.
Donc comparer un CISC avec un RISC demande cette gymnastique.

Pour un cœur, on a en MIPS :  68060 à 50 MHz ←→ d'un seul cœur d'un Intel Core 2 Quad Q9550 (à 999 MHz)
Les cœurs RISC sont obligés d'avancer 20 fois plus vite pour faire autant qu'un cœur CISC.

ares a écrit :

Tu prends le cas du Pentium, mais il n'y a aucune « dissimulation » RISC en CISC... car un programmeur sur langage de haut de niveaux ; il en a RAB !

Si tu le prends comme ça, ne perdons pas notre temps. Je parlais de TOUS les processeurs compatible i86 depuis le Pentium, donc les double-cœur, les QUAD, tout ça c'est du RISC. J'ai bien suivi l'histoire dans les années 1990.

Et encore je ne parlerai pas de la consommation électrique / MIPS …
(Atom est le plus performant coté PC je crois)

Dans un Langage de haut niveau, c'est obligatoire de connaitre l'architecture des ordinateurs pour éviter de pondre des algorithmes de merde que les compilateurs ne peuvent pas gérer normalement :

http://www-int.impmc.upmc.fr/impmc/Enseignement/ye/licence/calcul_int/cours/chap1/index.html a écrit :


Pour optimiser l’accès aux données il faut qu’un programme exploite des variables rangées à des adresses proches dans la mémoire de l’ordinateur. Lors de la première demande, il rangera dans le cache de données, une suite de variables qui auront de grande chance d’être rapidement exploitées et le fonctionnement du processeur s’en trouvera amélioré. Le gain peut dépasser 2 ou 3. Le programmeur peut forcer ce rangement en employant des tableaux et en les exploitant correctement.

Bref, les langages de «hauts niveaux» demandent un savoir technique. Comment imbriquer deux grosses boucles pour que l'anté-cache du processeur travaille normalement, et ne doivent pas se recharger à chaque opération.

Quant aux prédicteurs de branchements, que tous les informaticiens de la sécurité ont refusé, je vois très bien de quoi tu parles. Le prédicteur de branchement est la faille propre aux processeurs grand-public, et permet de casser les clé RSA : j'en parle dans un sujet sur le forum en 2008 wink

Bon dimanche.

#41 Le 12/10/2014, à 22:48

ares

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

L_d_v_c@ a écrit :

Si tu le prends comme ça, (...)

Ne nous fâchons pas smile

J'aurai du être plus précis, les programmeurs(système, jeu, etc) ayant besoin de connaître le l'architecture matériel CPU, GPU.
Et je pense qu'ils sont déjà "affranchis" sur le sujet (Pentium CISC/RISC).
Mais, je ne pense pas que le devs d'un ERP soit concerné pas l'architecture d'un CPU.

L_d_v_c@ a écrit :

Quant aux prédicteurs de branchements, que tous les informaticiens de la sécurité ont refusé,(...)

Là j'avoue, j'ai pas trouvé le lien entre extraire une instruction d'un pipeline CPU, pour une prédiction de branchement et un Root-kit* et Bios.
Car toutes les "puces" utilisent ce principe ou variante de l'Itanium, P8, Cell au i7 de madame Michu.
Et dans le cas d'un premier Pentium, le simple fait de d'invalider le cache L1(WBINVD) modifie le fonctionnement du pipeline.
Je suis pas expert, mais je connais pas l'instruction qui permet de lire le contenu de L1.
Cet instruction(WBINVD) est apparue sur 486 ; la "puce" est beaucoup plus lente.
Si tu as un lien smile

L_d_v_c@ a écrit :

Bon dimanche.

Merci,
Avec ce beau temps, j'ai crapahuté comme un abruti... un peut fatigué... mais y'a le lundi pour ce reposer au "taf". big_smile

J'espère que tu avais aussi beau temps...

@+

*) j'avais déjà lu ton topic smile

Hors ligne

#42 Le 13/10/2014, à 04:14

Compte supprimé

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

ares a écrit :

Là j'avoue, j'ai pas trouvé le lien entre extraire une instruction d'un pipeline CPU, pour une prédiction de branchement et un Root-kit* et Bios.
Car toutes les "puces" utilisent ce principe ou variante de l'Itanium, P8, Cell au i7 de madame Michu.

Si tu as un lien

Un Root-kit doit pouvoir surveiller tout ce qui se passe dans la machine. Un cheval de Troie suffirait-il à déchiffrer les clé RSA ?

https://interstices.info/jcms/c_25753/une-faille-de-securite-dans-les-processeurs a écrit :


Dans leur attaque expérimentale, Acıiçmez, Koç et Seifert analysent les états de prédiction de branchements définition du processeur. Comment ? Grâce à un processus espion qui s'exécute en parallèle du processus de cryptage. Les chercheurs ont baptisé cette technique Simple Branch Prediction Analysis Attack (SBPA). D'après les scientifiques, ces SBPA présentent un « risque de sécurité critique »

On the Power of Simple Branch Prediction Analysis

https://interstices.info/jcms/c_25753/une-faille-de-securite-dans-les-processeurs a écrit :


Ces mécanismes pourraient permettre aux pirates informatiques qui se seraient introduits sur la machine de déchiffrer indirectement les clés asymétriques utilisées habituellement pour protéger toutes sortes de transactions en ligne. Acıiçmez et ses collègues sont parvenus à acquérir 508 bits sur 512 d'une clé cryptée par RSA document externe au site. Le tout... du premier coup et en quelques millièmes de secondes.

(La publication date de 2007 - il ne restait que 512-508=4 bits à casser ! tant pis, 16 possibilités comparées à 1,340780793×10¹⁵⁴ possibilités qu'offraient les 512 bits…)

https://interstices.info/jcms/c_25753/une-faille-de-securite-dans-les-processeurs a écrit :

À titre de comparaison, il a fallu trois bons mois et une batterie de quelque 80 ordinateurs à 2.2 GHz pour que le bureau fédéral allemand de la sécurité informatique (BSI) parvienne à craquer une clé SSL definition à 640 bits.

De toute façon en 2013 :
Sécurité informatique: Des clés RSA de 4 096 bits cassées avec la cryptanalyse acoustique

Quant au cheval de Troie des BIOS : Computrace – Le mouchard universel présent sur les PC, Mac et appareils Android
Je donne des liens dans : VMBR et multiboot (Linux-xp) commencé en 2008 … (même ça peut fonctionner sans microsoft sur l'ordinateur. Par exemple : quiconque aurait utilisé la faille Bash actuelle pour installer un VMBR à partir de root.)

Dernière modification par Compte supprimé (Le 13/10/2014, à 04:21)

#43 Le 13/10/2014, à 09:05

Nasman

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

J'ai commencé à programmer en assembleur sur Commodore 64 pour accélérer certaines routines graphiques.
Sur commodore 64, le langage utilisateur était le basic mais en mode haute résolution, les routines basic mettaient quelque chose comme 30 secondes pour effacer l'écran graphique. Je me suis donc créé un assembleur basique (en basic) qui transformait les mnémoniques genre mov A, adresse en 3 octets, celui de mov, et des deux octets pour l'adresse 16 bits. L'assembleur ne gérait pas les étiquettes (il fallait compter les octets). Les lignes écrites en assembleur étaient alors transformées en successions d'octets, placées en mémoire vive avec des "poke". L'instruction basic sys adresse lançait le programme placé à adresse.

J'avais donc commencé par créer une routine qui effaçait l'écran graphique (quelques dizièmes de secondes contre 30 s), une routine qui traçait une ligne entre deux points ainsi qu'une routine de "remplissage".

Nostalgie des instructions pour processeurs 6502 et 6510 neutral


PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

Hors ligne

#44 Le 13/10/2014, à 21:51

ares

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

Salut L_d_v_c@ smile

Effectivement, grâce a tes liens c'est beaucoup plus claire... je cherchai dans un passé lointain ; vue que qu'il faut posséder un Pentium 4 HT
Bravo au équipes de chercheurs.
Il faut signaler aussi que la seul solution est donné en fin d'article :

Article a écrit :

Alors, gros temps en vue pour les fabricants de processeurs ? « Non, répond André Seznec. La nouvelle attaque n'implique pas une remise en cause de la façon dont les processeurs sont conçus. Mais elle montre que les développeurs d'applications cryptographiques doivent prendre en compte les aspects système et hardware de leur métier. Pour commencer, ce serait peut-être une bonne idée de désactiver le mode multithread sur les machines qui exécutent des programmes de cryptographie. »

Pour l'écoute des "composants"... la principale difficulté est la prise de son... savoir isoler les « vibrations » d'un PC dans le Neuf Trois ou d'un PC en cambrousse... entre les bruits urbains et les bruits de mère nature... je demande a entendre !

Soyons vigilant, la NSA est experte pour TOUT écouter sad

Hors ligne

#45 Le 15/10/2014, à 06:40

The Uploader

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

La vérité rétablie :
Amiga VS Atari ST
(la musique est simple sur Atari ST : y'en a pas)

Dernière modification par The Uploader (Le 15/10/2014, à 06:42)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#46 Le 15/10/2014, à 18:58

Compte supprimé

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

ares a écrit :

Pour l'écoute des "composants"... la principale difficulté est la prise de son... savoir isoler les « vibrations » d'un PC dans le Neuf Trois ou d'un PC en cambrousse... entre les bruits urbains et les bruits de mère nature... je demande a entendre !

Soyons vigilant, la NSA est experte pour TOUT écouter sad

Faisons confiance à la NSA qui n'a pas pour habitude d'effacer des documents chez des particuliers, en revanche, ils sont très bien équipés, et n'avaient pas besoin d'internet pour surveiller quelqu'un, ou un ordinateur déjà dans les années 1980, ou pour récupérer un fichier sur un disque dur, à distance, et sans internet. Le seul soucis à mes yeux reste qu'une entreprise entre dans les ordinateurs et volent des brevets …
Je pense que les Forces Spéciales ou la DCRI (en France) a les mêmes moyens que la NSA… Nous fabriquons moins d'ordinateurs piégés en usine en France, c'est tout.

#47 Le 15/10/2014, à 19:51

Compte supprimé

Re : X Marks The Spot by Portal Process (en 2010 : 65536 octets) 1ère place

The Uploader a écrit :

La vérité rétablie :
Amiga VS Atari ST
(la musique est simple sur Atari ST : y'en a pas)

Pas de trollage hein ? Atari n'avait pas les composants fabriqués sur mesures pour l'Amiga Commodores version AGA, les duals-playfiels ou le mode graphique transparence permettant de mixer les bitplans (mixer des images en temps réel avec des origines qui peuvent évoluer).
L'Amiga pouvait faire du genlock avec ces modes graphiques qui ne servaient pas que pour les jeux …

En 1998-1999 j'ai fait une présentation orale en anglais en diffusant un montage vidéo fait avec l'Amiga et enregistré sur une cassette VHS, j'ai pris du retard sur la cassette, je n'ai pas pensé mettre pause, mon oral était loupé mais tout le monde m'a demandé comment j'avais pu faire la vidéo, impressionnante avec des images, des graphiques et du texte qui défilait … Pas possible avec un PC grand public à l'époque … wink

Bon, j'avais un Amiga 1200, donc les jeux programmés pour les composants AGA étaient encore un cran au dessus de la démonstration ci-dessus qui semble ECS.
La plupart des jeux tournaient à 50 FPS (dans un des modes compatibles avec une télévision Secam/Pal).

Bien sûr il y avait un compromis détail/fluidité, en général la fluidité était assurée puis les programmeurs ajustaient les détails en fonction des ressources, et de l'ensemble AGA, qui permettait 256 couleurs dès 1992, et 262144 couleurs en mode HAM8 (peu de programmes tournèrent en HAM 8 sad )

Les vidéos Youtubes sont dégradées par rapport à ce que peut faire un A1200 d'origine (en mode AGA), donc à 50 images par seconde et sans saccade, ensuite les cartes accélératrices étaient un plus pour les calculs, mais rarement pour les jeux qui fonctionnaient pratiquement tous d'origine … avec un CPU 68000 à 7,14 MHz en ECS (enhanced chip set), ou un CPU 68020 à 14,28 MHz pour l'AGA … Puis les jeux étant souvent programmés bas niveau pouvaient nécessiter de redémarrer en OCS (original chip set) … compatible avec les composants d'origines.

Je me souviens avoir laissé travaillé l'ordinateur 11 heures pour générer un film de 30 secondes avec scenery animator, en images de synthèses à rendus fractales.

Sinon l'Amiga pouvait servir pour jouer : une vidéo Youtube qui résume l'ambiance graphique et sonore …
Amiga - Pinball Illusions AGA

Je n'ai pas trouvé de vidéo youtube de Pinball en AGA qui soit bien numérisée, laissant apparaître sur youtube des saccades qu'il n'y avait pas à l'origine sur un Amiga 1200 AGA.

Puis de toute façon, les gens qui n'ont jamais possédé d'Amiga ne comprendront pas que la puissance ne se mesure pas qu'en MHz, ou GHz, ni en Mo ou Go, ni en FPS …

édit : et cette histoire que je ressors souvent, un jour à carrefour avec ma mère pour regarder l'Amiga 1200 en vente à 3499 francs, à coté d'un PC qui n'en faisait pas la moitié, je ne sais même pas si le PC avait une carte son, mais PC vendu à 8000 francs. Un autre gamin avec sa mère demande à sa mère pour acheter l'Amiga 1200, ça mère répond que le PC doit être mieux … sad
Bien finalement j'ai acheté l'Amiga 1200 à la FNAC à 2990 francs.

Dernière modification par Compte supprimé (Le 17/10/2014, à 12:49)