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

Compte supprimé · Le 08/10/2014, à 08:27

La vidéo youtube suivante est en fait capturée d'un exécutable de 2010, en 65536 octets, pour le code, avec les graphismes et la musiques, durée 3mn44s.
X Marks The Spot by Portal Process | 64k (FullHD 1080p HQ HD Invitation demoscene 2010)

J'adore quand le robot se met à danser en musique, s'il-vous-plaît !
Bah oui, ils ont le droit à 65536 octets quand même pour produire leur démo qui contient du code, de la vidéo en 1080 FullHD, et de la musique !

Respect à eux !

tiramiseb · Le 08/10/2014, à 10:51

Je me demande comment ils arrivent à mettre tout ça dans une démo de 64 Kio. Bordel, comment c'est possible !?
Les démos m'ont toujours bluffé, depuis tout petit...

Compte supprimé · Le 08/10/2014, à 11:35

tiramiseb a écrit :

Je me demande comment ils arrivent à mettre tout ça dans une démo de 64 Kio. Bordel, comment c'est possible !?
Les démos m'ont toujours bluffé, depuis tout petit...

Ils codent en assembleur …

tiramiseb · Le 08/10/2014, à 11:39

Bien sûr. Mais ça ne rend pas la chose plus évidente...

Compte supprimé · Le 08/10/2014, à 12:36

Une autre démo, plus ancienne de 2003, dont j'ai récupéré l'exécutable, et qui est bien faite, impressionnante, et surtout, au générique de fin à 5'10", tu risques de ne pas en revenir en lisant les détails techniques ! à moins d'y être habitué …
Zoom 3 by AND | 64k intro (FullHD 1080p HQ demoscene demo)
J'ai l'exécutable de Zoom 3 qui fonctionne parfois avec Wine sous Ubuntu.

YEEEEEEEAAAAAAAAAAAAAAAAAHHH 510 octets reached !

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

tiramiseb · Le 08/10/2014, à 12:40

C'est du boulot vraiment impressionnant...

tiramiseb · Le 08/10/2014, à 12:40

Et à côté de ça, on a des jeux qui ont besoin de giga-octets dans tous les sens...

Compte supprimé · Le 08/10/2014, à 12:50

tiramiseb a écrit :

Et à côté de ça, on a des jeux qui ont besoin de giga-octets dans tous les sens...

Giga-octets, Giga-Hertz, ça fait vendre …

Ayral · Le 08/10/2014, à 16:07

L_d_v_c@ a écrit :

Ils codent en assembleur …

J'ai une idée théorique de ce qu'est l'assembleur, su je me souviens bien le code parle directement le langage machine, ou presque.
Mais comment peut on coder en assembleur ? C'est une langue parfaitement abstraite, non ?
Existe -t il beaucoup d'humains capables de coder directement en assembleur ?
Si ce n'est pas plus compliqué que ça, pourquoi tout n'est-il pas codé ainsi ?

Excusez mes questions sans doute idiotes. Il y a 20 ans, coder 5 lignes en basic me remplissait d'auto admiration, et maintenant je ne saurais même plus le faire !

tiramiseb · Le 08/10/2014, à 16:42

Ayral : l'assembleur est très difficile à maîtriser. Il faut donner toutes les instructions à un niveau très bas. On manipule les octets, on manipule les différents bus avec les adresses qui vont bien, on manipule directement la mémoire, etc.
Donc si, justement, c'est très compliqué
Et c'est pour ça que tout n'est pas codé en assembleur.

tiramiseb · Le 08/10/2014, à 16:43

Si tu veux, 5 lignes de BASIC peuvent correspondre à 10, 20, voire 30 lignes d'assembleur (selon les instructions utilisées)...
Alors imagine à quoi ressembleraient les programmes qui font actuellement plusieurs milliers, dizaines de milliers, centaines de milliers, voire millions de lignes dans certains cas, si tout était en assembleur...

Compte supprimé · Le 08/10/2014, à 16:49

Ayral a écrit :

J'ai une idée théorique de ce qu'est l'assembleur, su je me souviens bien le code parle directement le langage machine, ou presque.
Mais comment peut on coder en assembleur ? C'est une langue parfaitement abstraite, non ?
Existe -t il beaucoup d'humains capables de coder directement en assembleur ?
Si ce n'est pas plus compliqué que ça, pourquoi tout n'est-il pas codé ainsi ?
Excusez mes questions sans doute idiotes. Il y a 20 ans, coder 5 lignes en basic me remplissait d'auto admiration, et maintenant je ne saurais même plus le faire !

Non, tu confonds peut-être assembleur et LM (langage machine).
Peu de gens savent lire le code machine en hexadécimal.

L'assembleur (par exemple 68k chez Motorola, compatible 16 et 32 bits, le seul que j'ai vraiment bidouillé, n'allant pas plus loin que quelques exercices coté Intel 8086 - 8 bits…)

Le 68k, lire 68000, ressemble à :

debut:    move.w #1000, d0
boucle:   subq #1, d0
          bne    boucle         
          suite_du programme …
          nop   ;ne fait rien pendant un cycle par exemple …
          rts   ;fin de la sous-routine

C'est un compteur qui décompte de 1000 à 0 par pas de -1, qui teste le registre d0, et qui branche si "not equal" vers boucle ! C'est hyper-simple.
Ça c'est l'assembleur, et le langage machine ressemblera à
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 4E 71 4E 75

4E71 est le code de nop
4E75 est le code de fin de sous-routine

Donc oui, il existe des gens qui lisent, ou qui ont lu le code machine en hécadécimal, et qui déboguaient les programmes en hexa !
Moi je ne connaissais que 4E71 le code de nop et 4E75 le code de fin de sous-routine car ça aurait pu servir dans certains programmes de modifier une fin de sous-routine pour que le programme continue … surtout quand cette fin de sous-routine empêchait la suite du programme.
Mais je n'y suis jamais arrivé, il aurait fallu passer encore plus d'heures …

Sinon il existe des désassembleurs pour l'Arduino, pour Motorola, même x86 … en fait tous les processeurs, qui permettent de lire les programmes en convertissant automatiquement le code machine 68k par exemple : XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 4E 71 4E 75 en code assembleur (sans commentaire ):

debut:    move.w #1000, d0
boucle:   subq #1, d0
          bne    boucle         
          suite_du programme …
          nop   
          rts

Enfin c'est pour le principe, car l'étiquette boucle n'existe pas en désassemblage, ça devient un saut relatif de -4 par exemple. - C'est-à-dire que le programme reculerait de 4 octets si d0 est différent de zéro …
Et ça deviens plus simple de modifier un programme, ou de partir à la chasse aux erreurs.

Mais je ne suis pas allé plus loin que l'exploration de l'informatique industrielle en assembleur, avec des microcontroleurs MC68331 qui sont des 68020 (32 bits) avec en plus des entrées-sorties électriques à raccorder, des timers, en quelque sorte. Très utilisé pendant un temps …

Puis maintenant auto-formation Arduino, mais pas encore l'assembleur, je me contente du compilateur Arduino qui ressemble à du C.

Vidéo du 30/9/2014 : encore des choses à faire … et reste à câbler les 12 dernières guirlandes (en tout 24).
La rampe de lumières - sonnette - alarme CO - compteurs clients

Je trouve plus facile de coder en assembleur quand on a passé le temps d'apprendre l'assembleur dudit processeur cible, mais ce n'est pas portable, et il faut apprendre pour chaque famille de processeurs, ou prévoir et anticiper le code en fonction du processeur (du même fabricant, ou compatible), bref. Voilà pourquoi les langages C/C++, python, E, sont autant appréciés : pour leur portabilité.

SCHG:68000 ASM-to-Hex Code Reference

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

Elzen · Le 08/10/2014, à 17:12

L'assembleur n'est pas un langage prévu pour être humainement gérable.

Sauf erreur de ma part, les gens qui ont besoin d'écrire de gros trucs en assembleur ont tendance à d'abord écrire le plus gros en C, puis à utiliser un compilateur pour traduire ça en assembleur, puis à travailler manuellement sur les bouts qui restent, parce que le compilateur va pouvoir faire facilement des tas d'optimisations qu'un humain aurait de grosses difficultés à gérer.

Compte supprimé · Le 08/10/2014, à 17:48

tiramiseb a écrit :

Si tu veux, 5 lignes de BASIC peuvent correspondre à 10, 20, voire 30 lignes d'assembleur (selon les instructions utilisées)...
Alors imagine à quoi ressembleraient les programmes qui font actuellement plusieurs milliers, dizaines de milliers, centaines de milliers, voire millions de lignes dans certains cas, si tout était en assembleur...

Erreur mon cher Watson (tiramiseb),
1) penser programmation modulaire, où on découpe les taches, on préfère plein de sous-programmes ou sous-routines … on peut donc distribuer le travail, en suivant une méthodologie.
2) le programme assembleur sera plus petit bien souvent, l'exécutable parfois tellement plus petit pour remplir la fonction, donc tellement plus robuste et tellement plus rapide.

En revanche : dans le cas du Blitz Basic, certaines fonctions étaient très évoluées, et en effet pouvaient prendre l'équivalent de beaucoup de lignes de code en assembleur.

Mais l'assembleur a permis d'atteindre des niveaux d'optimisations par la pensée des programmeurs, que certains compilateurs ont eu du mal à concurrencer. Je ne sais pas ce qu'il en est aujourd'hui.

Mais faire appel à une fonction du basic par exemple, a pu entraîner la sauvegarde de tous les registres du processeur en entrant dans la sous-fonction, même s'il n'y avait besoin que d'un seul registre, et restaurer tous les registres avant de continuer le programme. C'est exagéré, mais c'est un peu ce qui se passait avec le multitâche de toute façon, par le protocole des appels par le système …

Plusieurs programmes qui utilisent les mêmes registres d'un même processeur : il faut constamment lire et remettre les registres du processeur afin de changer de tache, sans perdre trop de temps, tout en enchaînant tous les processus. Tout en obéissant aux interruptions logicielles et matérielles !
Ensuite la gestion des interruptions, des timers … les protocoles de communications,devoir parfois insérer des nop (null opérandes) avant de lire un signal électrique pour être sûr qu'il est bien établi …

Et l'Amiga de Commodore fut la machine personnelle la plus réussie au niveau du multitâche préemptif
Tu pouvais lancer le formatage d'une disquette et lire de la musique en même temps, alors qu'à l'époque sans GNU/Linux, windows devait choisir entre formater la disquette ou lire la musique, enfin le son par le buzzer avec windows …

Mais l'Amiga n'est pas un PC, L'Amiga est une vraie machine multitâches (mais mono utilisateur) avec des coprocesseurs spécialement conçus pour les Amiga, et le CPU de l'Amiga n'était pas le cœur de l'ordinateur. Le CPU permettait le fonctionnement en effectuant quelques opérations mais c'est l'ensemble de la machine avec les circuits Denise, Lisa, Agnus/ALice, Copper, Blitter avaient tous une ou plusieurs fonctions précises qui faisaient l'ordinateur. Donc, pas de cœur réel. On pouvait même par la prise vidéo prendre le contrôle sur le Quartz interne pour synchroniser l'ordinateur avec les magnétoscopes et faire du genlock (et incrustations d'images).
Le CPU obéissait comme un coprocesseur.

Le Blitter ne savait faire que 3 opérations ! Mais travaillait presque tout le temps, en déchargeant le CPU.

The blitter is a sub-component of Agnus. "Blit" is shorthand for "block image transfer" or bit blit. The blitter is a highly parallel memory transfer and logic operation unit. It has three modes of operation: copying blocks of memory, filling blocks (e.g. polygon filling) and line drawing.
The blitter allows the rapid copying of video memory, meaning that the CPU can be freed for other tasks. The blitter was primarily used for drawing and redrawing graphics images on the screen, called "bobs", short for "blitter objects".

La mémoire CHIP était multi-accès, accessible directement par tous les composants de la machine …

Et c'est pour cela que lire de la musique (puce Paula), pendant le formatage d'une disquette (le floppy disk controler et encore Paula), pendant l'affichage de sprites sur des animations (puces Denise, Blitter et Copper), se faisait à moins de 1% CPU !

En général, la plupart des ordinateurs Amiga n'étaient livrés qu'avec de la Chip RAM. Suivant les caractéristiques du chipset, il était possible d'étendre la mémoire jusqu'à remplir complètement l'espace d'adressage de la Chip RAM. À ce moment, toute mémoire ajoutée était réservée au processeur principal. L'ajout de cette mémoire, permettant au processeur principal de ne plus être bloqué par les accès à la chip RAM, l'ordinateur s'en trouvait accéléré, et tout naturellement on appela cette mémoire de la Fast RAM.

L'Amiga n'était pas en avance sur son temps, ce sont tous les autres qui étaient en retard d'environs 20 ans dans la souplesse, la fluidité et le multitâche.

Les processeurs Motorola étant mieux programmés et optimisés pour Amiga, j'ai obtenu en 2000 une équivalence d'utilisation entre mon Amiga 1200+1230 à 50 MHz, et Windows NT4 à 200 MHz.
Pourtant je rappelle que NT4 n'était pas Dos, rien à voir avec Win 95/98. NT4 tournait déjà mieux que 95/98, mais l'Amiga avec un processeur 4 fois moins rapide en fréquence d'horloge, réagissait à la même vitesse/latence.

L'Amiga était un ordinateur TEMPS-RÉEL dès son apparition en 1985 !

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

Compte supprimé · Le 08/10/2014, à 18:24

Elzen a écrit :

L'assembleur n'est pas un langage prévu pour être humainement gérable.

L'assembleur demande plus de rigueur que les C/C++ mais est parfaitement gérable humainement, mais comme je l'ai écrit plus haut, l'assembleur n'est pas portable.

Sauf erreur de ma part, les gens qui ont besoin d'écrire de gros trucs en assembleur ont tendance à d'abord écrire le plus gros en C, puis à utiliser un compilateur pour traduire ça en assembleur, puis à travailler manuellement sur les bouts qui restent, parce que le compilateur va pouvoir faire facilement des tas d'optimisations qu'un humain aurait de grosses difficultés à gérer.

C'est un peu l'idée, mais en fait, ce qui est écrit en C, reste en C.
L'assembleur est directement écrit en assembleur, permettant autrefois des optimisations que seul le programmeur restait maître.

L'AmigaOS et le Workbench : Un gros projet dans un tout petit système :
90% assembleur (pour optimisation des composants spécifiques vus plus haut)
9% en langage C (pour les parties non critiques)
1% Amiga-Shell-script
Possibilité d'utiliser Arexx: pour la communication entre les différents programmes …

Consommation minimale (en réduisant la profondeur de l'écran, mémoire CHIP partagée …) environs 200+20 Kio de RAM (bon en 2 couleurs …), donc 200+20×n bitplans (n=1 à 8, pour 2^n couleurs en 640×256 pixels par exemple au démarrage), donc atteignant 200+20*8=320 Kio de RAM environs pour le système minimal sans workbench, mais toujours Multitâches, permettant les menus à la souris, amigashell, et ensuite de lancer des programmes graphiques qui se greffent à la mémoire)

Je ne me servais que de 8 couleurs pour utiliser le logiciel de musique Octamed Sound Studio en 64 pistes audio mélangées avec éventuellement des pistes MIDI.

Et le plus fort : on pouvait mélanger les écrans virtuels et afficher une fenêtre en 2 couleurs en même temps qu'une fenêtre 256 couleurs.

gurumeditation

Et là ! en 1985 l'Amiga sort avec le mode HAM6, mais en 1992 ! L'Amiga 1200 sort avec le mode graphique HAM8 !!! 262144 couleurs parmi 262144 couleurs.
Les bons PC avaient 256 couleurs et continuaient de sonner le buzzer …

Compte supprimé · Le 08/10/2014, à 19:59

Elzen a écrit :

L'assembleur n'est pas un langage prévu pour être humainement gérable.
Sauf erreur de ma part, les gens qui ont besoin d'écrire de gros trucs en assembleur ont tendance à d'abord écrire le plus gros en C, puis à utiliser un compilateur pour traduire ça en assembleur, puis à travailler manuellement sur les bouts qui restent, parce que le compilateur va pouvoir faire facilement des tas d'optimisations qu'un humain aurait de grosses difficultés à gérer.

Finalement, tu viens de donner l'exemple d'un moins bon programmeur. Celui qui ne comprends même pas son programme, et qui doit d'abord le compiler pour voir où sa coince. Pire, qui corrige son programme au débogueur

Les bons programmeurs de ces démonstrations maîtrisent tout les moindres recoins du programme, et peuvent de dire d'avance à la nano-seconde près la durée de chaque portion, ou boucle du programme. Les instructions sont comptées en cycles d'horloges.
Donc tel ou tel sous-programme prendra tant de temps en fonction du nombre d' instructions, de la complexité et l'imbrication des boucles, et de la fréquence d'horloge du processeur.
Par le passé, les processeurs ne changeaient pas de fréquence d'horloge, et pourtant, il se peut que pour un meilleur rendu, le programme désactive le système d'exploitation, ou le mette en pause, afin de garder la disponibilité pour la démonstration, ou tout simplement désactive totalement le multitâche. (ce qui se faisait souvent sur Amiga pour ce genre de démonstrations 65536 octets, il y avait aussi les démos 40k (pourquoi 40 ? jamais sû) , les démos 4k ! et les démos 1024 octets !!! qui s'appelaient les démos boot-block (le boot-block en 2 secteurs de 512 octets sur la disquette, bien souvent …)

En tout cas, les programmeurs du passé, savaient à l'avance ce qui nécessiterait l'emploi de l'assembleur, et ce qui pourrait tourner en C, mais en général le C grossit le code et dépend du compilateur, donc on ne connait pas à l'avance le comportement exact du programme au nombre de cycle d'horloge près pour les situations critiques.

Une autre vieille technique de l'Amiga en revanche était qu'on ne programme pas deux fois la même chose !

L'utilisation des librairies devaient toutes être compatibles descendantes, et la création de librairies devaient être documentées avec les offset d'entrées.

Les librairies principales étaient pratiquement toutes en ROM dure. Si une rare nouvelle version, compatible descendante, apportaient de nouvelles fonctions, alors elle était stocké dans le répertoire LIBS: où on y retrouvait toutes les autres librairies utiles aux programmes, qui pouvaient ensuite partager des mêmes librairies, qui devaient être commentées avec un protocole, etc …

Livre : Amiga ROM Kernel Reference Manual: Libraries (3e édition) - 592 pages en papier !

Et là ceux qui n'ont pas connu Amiga tomberont de leur chaise, attention ! Voici la documentation d'une seule library souvent utilisée, avec tous les registres de communications entre la librairie, et le processeur :
Manuel d'utilisation d'exec.library avec l'explication des registres utilisés le processeur.

D'autres librairies adressaient d'autres composants, mais fonctionnaient sur le même principe.

Un truc de geeks qu'on j'y repense !

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

tiramiseb · Le 08/10/2014, à 20:20

Halala ça me rappelle des souvenirs

Je me suis essayé à la programmation assembleur sur Motorola 68000 en cours (« comme tout le monde », j'ai envie de dire... enfin comme tout le monde qui a suivi ce genre de cursus, quoi...), mais surtout sur Saturn... et je peux vous dire que bosser avec un bus 4 bits, des registres 64 bits et une mémoire 8 bits, ça demande pas mal de gymnastique du cerveau

Compte supprimé · Le 08/10/2014, à 20:51

tiramiseb a écrit :

Halala ça me rappelle des souvenirs
Je me suis essayé à la programmation assembleur sur Motorola 68000 en cours (« comme tout le monde », j'ai envie de dire... enfin comme tout le monde qui a suivi ce genre de cursus, quoi...), mais surtout sur Saturn... et je peux vous dire que bosser avec un bus 4 bits, des registres 64 bits et une mémoire 8 bits, ça demande pas mal de gymnastique du cerveau

Je n'ai pas connu le Saturn, mais les démonstrations programmées en assembleur avec les Yorke sur HP 48 étaient impressionnantes !
bus 4 bits, réflexe, → HP 48 … pas loin

J'ai une TI 92+ que j'ai gardé d'origine, plein de programmes natifs personnels en analyse numérique, module universitaire en licence EEA.
À la fin de l'année, je rends la feuille au bout de 40 mn, après avoir passé 10 mn à relire. J'étais le premier à rendre la copie d'examen. Le professeur me demande en bas de l’amphithéâtre quand je m'approche du bureau : «il y a un problème ?» à voix basse, je lui dit :«non non, tout est juste …»
L'examen durait 1h30.
J'était pourtant plus ou moins freiné par neuroleptiques, mais l'analyse numérique ça allait j'avais bien travaillé.
Oui, 20/20. Normal. Ça m'a rattrapé les mathématiques à 8/20 puisque je n'ai pas fait le bac S pour entrer en Deug TI GE (donné à 99% d'échec la première année, et à 99,8% d'échec la deuxième année lors de mon inscription universitaire. Mais j'ai eu le DEUG en prenant tous les modules optionnels non scientifiques que je pouvais la deuxième année : sport, et «art et sciences : musique électroacoustique» au conservatoire de Bordeaux ) , puis licence EEA qui correspond à la troisième année, que j'ai triplée sur 4 ans (1+1+1/2+1/2). Mais je l'ai eu ! Sans utiliser le tiers temps dont j'aurais pu disposer en tant qu'hospitalisé en hôpital de jour.

Sinon, une démo récupérée de Teris en 4 niveaux de gris et en assembleur, mais je n'ai jamais attaqué l'assembleur de la TI92+, bien que 68000 à 20 MHz …
La TI92+ est intéressante pour son système d'exploitation scientifique. Mais l'université ne me laisser pas trop le temps de me distraire …

tiramiseb · Le 08/10/2014, à 20:53

Ouais enfin quand je parle de Saturn je parle de la série hein. J'ai une HP 48G+ donc j'ai un Yorke

Compte supprimé · Le 08/10/2014, à 20:57

tiramiseb a écrit :

Ouais enfin quand je parle de Saturn je parle de la série hein. J'ai une HP 48G+ donc j'ai un Yorke

Ah je ne connais pas, différents noms pour une série compatibles descendante ? comme 68000 → 68008 → 68010 → 68012 → 68020 → 68030 → 68040 et → 68060 ?

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

tiramiseb · Le 08/10/2014, à 20:59

C'est décrit dans la page de Wikipedia en lien dans mon message #17.

Compte supprimé · Le 08/10/2014, à 21:01

J'ai mal lu ton lien Saturn, j'ai cru que c'était le nom de code du processeur à 640 kHz, mais c'est la « famille de microprocesseurs Saturn a été développée dans les années 1980 par Hewlett-Packard pour en équiper des ordinateurs et des calculatrices scientifiques programmables. »
Désolé, fatigué, direction dodo
Bonne nuit à toi tiramiseb

The Uploader · Le 08/10/2014, à 21:04

L_d_v_c@ a écrit :

]Et là ! en 1985 l'Amiga sort avec le mode HAM6, mais en 1992 ! L'Amiga 1200 sort avec le mode graphique HAM8 !!! 262144 couleurs parmi 262144 couleurs.
Les bons PC avaient 256 couleurs et continuaient de sonner le buzzer …

En fait avec Doom en 1993 le PC a écrasé l'Amiga.... Et aussi grâce au VGA, aux SoundBlaster, la baisse du prix des PCs, l'introduction de l'UDMA, du PCI, etc... et le fait que le PC était prédominant aux USA. :-)

Et l'A1200 avait très peu d'intérêt sans carte accélératrice 68k super chère. Son architecture matérielle était inexploitable sans ça.
L'AGA de l'A1200 c'était de belles promesses mais au final c'était inexploitable sans carte accélératrice. : et très peu de jeux/applis l'utilisent vraiment (et y'en a pas mal c'est juste les mêmes jeux qu'avant mais en version AGA, un peu comme les éditions HD à l'intérêt limité des jeux d'aujourd'hui ).

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

ares · Le 08/10/2014, à 22:41

!!! ATTENTION !!!

Impossible de critiquer l'Amiga... L'Amiga est « LA » machine de référence, le « bijou » technologique qui a brillé grace à une conception intelligente et « TRES » abordable pour l'époque.

À cette époque il y'a Amiga...
- en dessous : rien
- toujours en dessous : ben... rien
- encore en dessous : toujours rien
- toujours en dessous du dessous : désolé rien
- vraiment très très très en dessous : rien
- (...)
- en dessous du dessous... là c'est le fond.... : le "reste" du silicium pas utilisé pour un Amiga !

Un ordi se jette, brûle, explose, se recycle... un Amiga c'est pour la vie, l'éternité.

Je ne suis pas un partisan de l'Amiga... puisque je n'ai jamais possédé d'Amiga

Et pourtant, je sais que ce que les lignes qui suivent ne feront pas plaisir à L_d_v_c@
A cette période 1996 (pour moi)
La gamme Iapx86 d'Intel est plus simple pour la mise en oeuvre d'un OS multitâche préemptif.
Le mode "protégé" du 68020 Motorala est beaucoup plus compliqué.
Il y'a aussi les circuits annexes de la famille d'un CPU, cet ensemble fait la différence pour les industriels.
Et enfin un "bus" pour étendre l'ordinateur... il a même été commercialisé une carte d'extension 68000 pour PC
Intel avait de l'avance sur Motorola... mais sa technologie a subit un handicape, que dis-je un boulet : Microsoft avec DOS et un NT pourri au début

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

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

Et puisque mon "post" n'a ni queue ni tête, mon ancien "prof" époque : "sexe,drogue, Rock and Roll" aimait citer la phrase d'Alan Kay :
« La meilleure façon de prédire l’avenir est de l’inventer »
Pour l'ignare que je suis... ce monsieur était ingénieur au centre de recherche de Xerox (PARC).
Avec d'autres ingénieurs, ils ont inventer la "Star" qui fut un échec commercial !
2 ans plus tard ; le "Mac" d'Apple pale copie de merde de la "Start" de Xerox sera plébiscité.
Même si la conception est correcte pour l'époque... rien à voir avec la technologie ingénieuse et novatrice d'un Amiga.
Je me demande d'ailleurs si "l'Amiga" n'est pas une formidable copie issue des travaux du PARC Xerox

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 ~~~~~~~>[]

Dernière modification par ares (Le 08/10/2014, à 22:43)

tiramiseb · Le 09/10/2014, à 07:29

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

Et au-dessus : Atari ST.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/10/2014, à 08:27

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

#2 Le 08/10/2014, à 10:51

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

#3 Le 08/10/2014, à 11:35

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

#4 Le 08/10/2014, à 11:39

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

#5 Le 08/10/2014, à 12:36

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

#6 Le 08/10/2014, à 12:40

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

#7 Le 08/10/2014, à 12:40

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

#8 Le 08/10/2014, à 12:50

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

#9 Le 08/10/2014, à 16:07

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

#10 Le 08/10/2014, à 16:42

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

#11 Le 08/10/2014, à 16:43

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

#12 Le 08/10/2014, à 16:49

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

#13 Le 08/10/2014, à 17:12

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

#14 Le 08/10/2014, à 17:48

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

#15 Le 08/10/2014, à 18:24

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

#16 Le 08/10/2014, à 19:59

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

#17 Le 08/10/2014, à 20:20

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

#18 Le 08/10/2014, à 20:51

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

#19 Le 08/10/2014, à 20:53

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

#20 Le 08/10/2014, à 20:57

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

#21 Le 08/10/2014, à 20:59

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

#22 Le 08/10/2014, à 21:01

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

#23 Le 08/10/2014, à 21:04

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

#24 Le 08/10/2014, à 22:41

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

#25 Le 09/10/2014, à 07:29

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

Pied de page des forums