Re: Amiga/st vs Archimede

[Invité]

Non le CD n'apporte rien de plus que de la RAM cache (pour remplacer la hucard), et une voie adpcm pour les samples(avec 64 ko) .
Sur scd-rom² tu auras 256 ko de cache pour les données .

Sa demo je suis carrément sur de la faire sur une simple PCE, la SGX qui n'est q'une pce avec un second vdc (chip vidéo) et 32 ko de ram, la pas de soucis, car j'aurai pas de problème pour le nombre de sprites/ligne .

Sa demo n'a vraiment rien d'extraordinaire, à par pour l'archimedes peut être .

j'adore les specs de sa demo, on pourrai croire à 3*256 couleurs lol .

- 1 background de fond en scroll vertical en 256 couleurs (*)
- 3 gros sprites à l'écran en 256 couleurs (*)
- 1 scrolltext en 256 couleurs (*)

[babsimov]

J'en ai déjà parlé au début de la file.
Vos Amiga, ST et mon Archimedes ont tous eu des cartes x86 en cartes d'extension.
Ca coutait un bras, à cause de l'interfaçage avec le reste de la machine, l'embarquement de RAM etc.... en gros c'était un PC quasi complet sur une carte d'extension.

L'idée du RISC PC c'est que le 2è slot processeur permet de communiquer directement, facilement je dirais, avec tous les autres composants du RISC PC.
Du coup la carte 2nd proc est légère, et moins couteuse.

Et non : le RISC OS ne gérait pas le second processeur, on est loin de la BeBox.

Dans ce cas, quel est l'intéret d'avoir deux processeurs ARM dans le RISCPC s'ils n'étaient pas géré par l'OS ? Si j'ai bien compris le processeur X86 lui servait à faire tourner les applications PC. Mais le deuxième ARM il servait à quoi ? Un simple copro mathématique ? Dans ce cas il ne faut pas dire que le RISCPC fut le premier ordinateur bi processeur, c'est faux. Le principe des copro mathématique existait bien avant. Comme je l'ai dit, la Bebox me semble être la première machine réellement conçu pour ça (hormis les stations de travail haut de gamme, mais qui ne visaient pas le grand public).

Sur un RISC PC les 2 processeurs sont sur carte fille, quand tu veux changer de proc tu changes de carte fille.

Le principe de la carte fille pour le processeur existait aussi sur l'Amiga 4000. Malheureusement, Commodore ne l'a pas vraiment utilisé.

Acorn a conçu le RISC PC pour la compatibilité avec le monde x86 : faire tourner windows en environnement fenêtré sous RISC OS, ou bien en 'full ressource'.
Sous RISC OS, on pouvait tranférer les fichiers d'un monde à l'autre, de manière transparente, par 'drag'n drop' comme sur Windows actuel. (M'enfin ça ça existe depuis l'origine du RISC OS)
A noter aussi : possibilité d'utiliser l'unité de calcul flottante du x86 au lieu de celle de l'ARM, pour les programmes natifs ARM.

Carte fille ARM (610 ou 710) :


Carte fille x86 :

A noter : le max qu'on ait eu c'est de l'AMD DX4/133.
Comme tu le vois, il y a le proc, un gros ASIC, parfois un peu de mémoire cache externe, mais aucune RAM ou autres composants (vidéo, son etc ...), puisque ces ressources là seront celles du RISC PC.
C'est élégant comme solution, non ?

C'est effectivement une solution élégante, vers laquelle Commodore s'orientait pour le futur avec l'architecture Acutiator qui n'a pas pu exister en raison de la disparition de Commodore.
Je ne nie pas qu'Acorn ait conçu un belle machine et surtout un bon processeur.
Il reste encore la question du multitache de RISCOS. En cherchant sur internet je n'ai trouvé que des mentions d'un multitache coopératif. Cela correspond au souvenir que j'ai de cette époque. C'est en grande partie à cause de ça que j'ai rejeté l'Archimède. Pour moi ça aurait été un retour en arrière après AmigaOS et son multitache préemptif et très réactif.
Autre remarque, quel est l'intéret avec un processeur RISC, qui est censé être très bon pour le calcul, d'utiliser la partie calcul flottant du X86 ? Surtout s'il y a un second ARM qui est utilisé comme copro mathématique ? J'ai peut être mal compris ?

[babsimov]

Pour ce qui est du système ROM, ça a des avantages certes, mais un inconvénient majeur, c'est pas évolutif. Sauf à rajouter un disque dur, ce qui finalement revient à avoir une ROM de boot et le système à jour sur un disque dur. Donc ce que Commodore avait finalement retenu pour l'Amiga. Le tout en ROM je suis mitigé au final.

humrf...

si la ROM est en effet soudé à la Carte mère, c'est tout ce que tu as dit, mais sinon il y avait les solution de foutre la ROM sur un Socket, c'est donc évolutif même si personne (enfin pas les gamins qui n'y connaissaient rien, comme moi quoi) n'allait ouvrir la machine et changer la puce... ou alors le fumeux port cartouche... et là c'est hyper trivial de changer l'OS en ROM, le hic c'est alors que les fabriquants ne fournissaient pas forcément de bons trucs...

Sur tous les Archies la ROM est bien évidemment sur socket.

Il y a eu 3 versions de RISC OS pour les machines pré RISC PC :
- RISC OS 2.00, vite remplacé par
- RISC OS 3.00
- RISC OS 3.1 : quelques optimisations ajoutées et meilleure gestion réseau
- RISC OS 3.11 : petites corrections, et version allemande.

A noter un point fondamental : le RISC OS c'est un noyau central avec moults modules autour.
Si, et c'était extrêmement rare, un module n'était pas au top, les applis vendues fournissait le nouveau module, qui supplantait le précédent.
Voilà : beau, net, intelligent.
En 1 mot : Acorn.

Acorn n'a rien inventé du tout à ce niveau.

Sur AmigaOS aussi il était possible de patcher les ROM en corrigeant ou ajoutant des fonctions. Ca se faisait par un simple ajout d'une ligne dans la startup-sequence. Merci à AmigaNews pour avoir aussi bien expliqué comment fonctionnait l'Amiga. On pouvait alors voir que c'était bien un Ordinateur novateur.

La question reste le multitache sur Acorn : coopératif ou préemptif ? Il me semblait avoir lu quelques part qu'une version de RISCOS était devenu préemptif. Mais est ce bien compatible ? Chez Apple ils avaient engagé Carl Sassenrath (le créateur d'exec, le noyau multitache de l'Amiga) pour transformer MacOS en multitache. Il leur a répondu que c'était impossible sans tout réécrire. Résultat Apple a garder MacOS jusqu'à ce que MacOS X apparaissent, basé sur NextStep (donc unix).

Pour ce qui est des Rom sur Socket, c'était évidemment le cas aussi sur Amiga. Mais changer une ROM quand on est pas "spécialiste" c'est quand même moins accessible que d'installer une nouvelle version de son OS sur disque dur. D'autant plus que si je me souviens bien les Archimèdes avait un connecteur disque dur d'origine ? A moins que ce soit des modèles après 1988 ?

EDIT : Je lis que la version 3.11 des ROM apportait l'allemand. Ca veut dire que RISCOS n'était pas en français ? Comment était géré le clavier Azerty ?
Sur Amiga le clavier azerty était géré par le système depuis la version 1.x (la ROM étant en anglais pour toute les versions).
A partir du 3.0 le système est traduit dans toutes les langues grâce au système locale.library. Cela veut il dire qu'il n'existait rien de similaire sur RiscOS ?

A noter que le concept de la locale.library a été évoqué dès la version 1.4 du système. Mais, comme toujours, Commodore n'a pas mis assez d'argent pour que ce soit développé à temps pour le 3000 !

[babsimov]

PS : J'ajouterai que l'Archie a, lui, dès sa version de base 1 Mo de RAM, et son OS est dans une ROM de 512 Ko.
C'est sûr on est loin du concept console de jeux avec clavier de l'Amiga de base et ses 512 Ko.
Sur Archie, travailler sans disque dur, et sans un 2è lecteur de D7, ne pose pas de soucis, d'autant plus que l'OS gère le RAMdisk comme un filing system... sur le A500 on en est loin, bien loin de cette intelligence de conception. Ah évidemment l'Archie était plus cher, mais c'était bien justifié.

Le concept de l'Amiga date de 1982, Commodore ne l'a, certes, commercialisé qu'en 1985. A l'époque 512 Ko coutait très cher (le 1000 n'avait que 256 Ko), mais Jay Miner voulait 512 Ko, il savait que c'était le minimum nécessaire.
Sur AmigaOS aussi le RAM disk était un file system, ça s'appelait le RAD:
L'Archimède 3000 avait 512 Ko de RAM de base en 1989. A cette époque les 500 étaient vendu le plus souvent avec l'extension mémoire qui les portaient à 1MO. Ils étaient aussi moins cher que l'Archimède.
L'Archimède était un vrai 32 bits. Pour moi, l'Archimède était une belle machine. Mais, son seul coté novateur était d'être le premier ordinateur RISC et 32 Bits accessible. Son processeur était très bien conçu, l'avenir l'a démontré.
Tu ne peux nier que l'équipe d'origine de l'Amiga a réuni les meilleurs concepts de l'époque et les a démocratisé. L'Archimède n'était pas aussi révolutionnaire à sa sortie.
Que reste t il de l'Amiga me diras tu ?
- Le plug and play (autoconfig). Contrairement à ce que j'ai lu ici, le bus Zorro était bien supérieur au bus ISA du PC, il était déjà plug and play avant que ce mot ne soit inventé. Sur Amiga ça existait depuis l'origine, ça s'appelait l'autoconfig. Comme l'avait si bien titré Byte en 1985 "Dix ans d'avance" :)
- La démocratisation du multitache préemptif. Je me souviens encore du monde PC/MAC qui, à l'époque, prétendait que ça servait à rien (comme les STistes d'ailleurs). Mais pourtant avec windows95 on nous l'a servi le soi disant "miracle" du multitache (qui d'ailleurs ne fonctionnait pas bien sur windows95) et le MAC l'a attendu longtemps.
- La démocratisation du multimédia, l'Amiga à montré la voie. Avant lui, pas de milliers de couleurs à l'écran, pas de son stéréo.

Certes "physiquement" il ne reste rien de l'Amiga, mais les OS actuels se sont inspirés des concepts que l'Amiga fut le premier à réunir ensembles et à démocratiser.

Malheureusement, comme Acorn, Commodore n'a pas su exploiter sa machine pour qu'elle devienne un standard reconnu. Jean Louis Gassé, le créateur de Be, a dit qu'à la sortie de l'Amiga, chez Apple on avait peur que ça écrase le MAC. C'était tout à fait compréhensible :
- Multitache préemptif
- Couleur
- Stéréo
et en face : monochrome, monotache !

Laisser entendre que l'Amiga n'a pas été conçu intelligemment, c'est faux ! Ce fut une machine pensée par des passionnés pour offrir le meilleur rapport prix/performance à son époque. Ils y croyaient tellement qu'ils ont prit hypothèques sur hypothèques pour que leur rêve devienne réalité ! Je pense pas qu'Acorn ait eu une histoire aussi mouventée et passionnante que l'Amiga ?
Si l'ARM avait existé en 1982 quand Jay Miner a conçu l'Amiga, qui te dit qu'il n'aurait pas tout simplement choisi ce processeur en adaptant les copros Amiga pour lui ? Le 68000 était à l'époque un processeur utilisé dans les stations de travail, ce n'était pas un sous processeur ! C'était un choix logique, surtout que l'idée de l'Amiga, Jay Miner l'avait défendu auprès d'Atari déjà en 1980, soit juste après la sortie du 68000. Il voulait faire une machine autour du processeur le plus puissant de son époque.
Même IBM avait prévu le 68000 pour les PC, mais à finalement choisit Intel parce que c'était moins cher. Toutes les machines de cette époque ont choisit le 68000.

J'ai lu que tu trouvais que la génération AGA des Amiga était une bien meilleure conception ! Je suis pas du tout d'accord. Ce ne sont que des machines sortie en hate, parce que Commodore n'avait pas mis assez d'argent dans la recherche pour sortir le AAA. Ca c'était une réelle évolution du concept Amiga et ça date de 1988 ! De même que Hombre s'annonçait très prometteur.

http://obligement.free.fr/articles/aaa.php
http://obligement.free.fr/articles/hombre.php

EDIT : Toujours pour l'AGA, j'ai aussi lu que le fait d'avoir gardé Paula du chipset d'origine bridait considérablement le 680x0. Dans le concept d'origine les accès prioritaires des copros vers la Chip n'enlevait que 10 % de la puissance CPU. Mais en gardant Paula dans l'AGA, cela à conduit à enlever 50 % de la puissance CPU s'il n'y avait pas mémoire fast. Je ne peux absolument pas t'expliquer pourquoi, je suis pas programmeur. Mais j'ai lu ça sur internet en surfant. C'était un programmeur qui expliquait à quel point l'AGA avait été bourré d'erreur de conceptions et ça montrait que ce n'était qu'un mauvais hack, comme l'ECS. Tout comme le blitter de l'AGA qui tourne au final à la même vitesse que celui de l'OCS mais avec un bus 32 bits. Il y a eu des améliorations, mais le minimum du minimum. Tiens par exemple il expliquait que les résolution en 31khz prenaient quasiment toute la bande passante. Il aurait été plus judicieux de ne pas mettre ces modes graphiques et d'intégrer la puce flicker fixer Amber du 3000 pour passer les résolutions 15khz entrelacée en 31khz non entrelacée. Résultat l'AGA aurait eu un affichage 256 couleurs haute résolution utilisable). Ce qui a été démontré récemment puisque quelqu'un à diffusé un mode 800x600 256 couleurs 15khz qui offre une vitesse d'affichage 75% plus rapide !!! Bien sur, il faut une carte indivision (flicker fixer) pour désentrelacer. Il est à noter que la puce Amber existait depuis l'Amiga 2000 et qu'elle était donc rentabilisé. Peut être aurait il fallu une petite adaptation pour gérer la palette 24 bits de l'AGA, mais ça aurait donné une bien meilleure machine.
A ce propos le 1200 et 4000 ne devaient pas du tout être les machines AGA qu'on aurait du avoir. A la place on aurait du avoir le 1000+ et le 3000+ (avec un DSP 3210 AT&T) :
http://www.amigahistory.co.uk/prototypes/1000plus.html
http://www.amigahistory.co.uk/prototypes/a3000plus.html

Je m'excuse d'avoir été aussi long, mais il y a beaucoup à dire sur l'Amiga et sa passionnante histoire.

[ArchieForEver]

Pour la Dragons, seules les 8 1eres minutes vont nécessiter de bien être feinteux sur Archie pour reproduire cet effet.
Le reste est bidon, surtout pour les vector bobs : c'est la technique de mémoire de trame qui est employée, autant dire du 'bidon de chez bidon'.
C'est sûr, quand tu vois ça, tu fais 'whhhaaa mon amigwhaaa keskiléfor' et quand tu vois la démo RiscDream d'Armaxess tu fais 'bof', alors que la logique voudrait que tu inverses ton jugement.
Cherche sur Internet la grosse feinte employée, tu comprendras peut-être pourquoi ce que tu admires tant est si moche et si brouillon, l'explication tient à la technique employée.
C'est fatiguant de discuter avec des incultes. Je me sens bien seul.

trop puissant, tu sorts la traduction de framebuffer en francais pour faire intelligent ..
C'est une technique vieille comme le monde de l'info celle là, que le mec qui a fait scorpius à surement utilisé .Et cette technique est utilisé quasiment pourtout et par tout le monde, c'est une super technique vachement utile, souvent utilisée pour fluidifier un scrolling .
Son utilisation n'a rien d'un effet de gros nuls comme tu le laisse entendre .
La fin de ton com est à mourrir tellement tu te prends pour un genie

sais tu ce que simuler ou trics veulent dire en infos ??
Non apparemment, mais serieusement plus ca va plus je me demande si tu sais programmer .
un trics ou bidouille en français, veut dire que l'on fait de facon détournée un effet qui n'est pas prévu en hard sur une machine .Donc tout ce que tu fais à l'écran comme effet, qui n'est pas prévu à l'origine dans la machine, est un tric .
Aucune, mais alors acune machine ne peut se targuer de n'avoir jamais eu recours aux trics .

Un dual playfiel logiciel est un tric, un effet raster sans interruptions raster est un tric, afficher 40 sprites à l'ecran alors que la machine n'en gère qu'un en hard est un tric, faire du syncscroll est un tric, jouer une musique sur 8 voix alors que la machine n'en gère que 4 est un tric,changer de couleurs à la mano pendant un hsync est un tric . .

Ps j'attends encore les commentaire sur ta viedeo youtube de ta demo, du style wouhaaa,c'est trop beau,trop fort etc, des vrais programmeurs, puisqu'ici personne n'est apte à voir ton immense talent ...

LOL, mon explication sur le DMA du charabia pourtant elle est plus que simple, mais bon si tu n'y comprend rien dsl, je peux rien faire pour toi .
que les données de BP soient contigues ou pas, le DMA, s'en branle, il envoit X données de l'adresse A à l'adresse B, donc si tu veux juste toucher un BP précis, c'est au prog de la faire , le DMA il va pas te changer tout les BP 2 d'une ligne par exemple tout seul .
tu veux du charabia, et bien je reprend ton explication (enfin ta quote) du manuel archimedes

Voici ce que dit la doc page 4-7 :
'Video Palette Logical Colors 0-FH: Adresses 00-3CH
In 1, 2, and 4 bits per pixel mode, data bits D12-D0 define the physical color corresponding to that logical color.
The data bus encoding is shown in Figure3.
Figure 3. Video palette logical color format
Bits 24, 25 , 30 et 31 : 0
Bits 29 à 26 : couleur logique
Bits 13 à 23 : ne pas modifier
Bits 0 à 12 : couleur physique

Figure 4 shows the physical color field specification.
Figure 4.
Renomons les bits 0 à 12 D0 à D12 ça donne :
D3-D0 define the red amplitude
D7-D4 define the green amplitude
D11-D8 define the blue amplitude
D12 defines the supremacy bit for that color

In 8 bits per pixel mode, only 9 bits are defined as shown in figure 5.
Figure 5. Video palette data encoding for 8 bits per pixel mode.
Dur à copier alors voilà en termes de bit :
Fixés à 0 : bits 31, 30, 25 et 24
Bits 26 à 29 : couleur logique
Ne pas programmer : bits 13 à 23, 11, 7, 6 et 3
Bits 12, 10, 9, 8, 5, 4, 2, 1, 0 : donnée pour la couleur physique


The palette outputs define the least significant bits of each color.
The most signifcant bits for each color now come directly from the upper 4 bits of the logical color field, giving the physical data field as shown in Figure 6.
Figure 6. Video palette definition for 8 bits per pixel mode.
Là attention ça décoiffe :

12___|11____10___9___8|___7____6___5___4___|___3___2___1___0
SUP__|______BLUE______|______GREEN_________|____RED
D12*_|L7**_D10*_D9*_D8*|L6**_L5**_D5*_D4*_|L4**_D2*_D1*_D0*

*Dn : these bits are from the palete field
**Ln : these bits are from the logical field.

Putin imbitable quand tu prends des infos sorties de leur contextes, et que tu n'expliques pas, parce que tu ne les a pas comprises .

c'est forcément techniquement faux.
Un DMA va fonctionner avec un pointeur d'adresse.
Bien évidemment si tu es en données entrelacées, un seul DMA sera suffisant.
Si tes bitplans sont en zone mémoire distincte (contigües), il faudra bien autant de DMA que de zone mémoire distincte pour lire les données.
Tout ça parcequ'il ne peut y avoir qu'un pointeur d'adresse mémoire par DMA.

Celle là faut l'encadrer lol, elle est tout bonnement surpuissante .

Un DMA ne transfère que des données d'une adresse mémoire à une autre, point barre .
Le mode graphique (chunky ou BP), mais il s'en branle comme l'an 40 ..
Et aucun intérêt de modifier juste un BP via DMA, c'est plus rapide via cpu avec les fonctions de transfert de blocs .
le DMA est utile pour de gros transferts de blocs, pas pour transférer 2 octets .

Franchement je sais maintenant que t'es aussi programmeur que moi chirurgien .
j'arrête la, j'en sais assez lol .

Je reprendrai plus en détails ce que tu avances mais visiblement le manque de compétence est de ton côté.
Un DMA agit par transfert de données depuis une zone mémoire vers un composant comme un coprocesseur, qu'il soit graphique ou son ou autre, afin de transformer les données lues sans utiliser le CPU, pour produire la trame vidéo, le son à produire, ou autre.
Donc, comme je l'ai déjà dit, puisqu'un DMA va utiliser une adresse de base pour démarrer le transfert mémoire, et bien dans le cas de la vidéo, si tu as un mode chunky, tu n'as besoin que d'un DMA ( tu pointes sur la mémoire vidéo à lire. Elle est unique : c'est la trame à afficher, et elle est codée séquentiellement (=chunky) ).
Par contre si tu es en mode bitplan, et que tes plans ne sont pas entrelacés, bien évidemment il te faut un DMA et une adresse pour pointer sur chaque plan.

Ou alors l'Amiga est vraiment une machine magique et avec un DMA il est capable de lire depuis des adresses multiples ce qui serait bien extraordinaire.

En dernière possibilité, DMA ne signifie pas la même chose chez Commodore et chez Acorn.

Pour les données sur le format de la couleur, on voit que la définition est un mélange de la valeur logique avec des valeurs physiques.
Si je l'ai posté ainsi, c'est bien parce que c'est assez obscure, et ça vient directement de la doc de VLSI.
Comme je l'ai dit, je ne connais rien aux subtilités de la formation des couleurs, donc je suis bien incapable de dire si cette structure a ou non une logique en elle même.

Pour ce que tu nommes trics etc .. etc ... on ne parle pas de la même chose.
J'ai déjà détaillé ce que je trouvais ridicule dans les démos Amiga et ST, il suffit de me relire.
Trics et optimisations n'ont rien à voir. Je laisse les lecteurs reprendre mes commentaires, ils sont bien assez clair (pas pour toi vue ta mauvaise foi, mais bon je n'en ai rien à cirer).

[oiseau de proie]

Mais, comme l'a dit touko (qui ne mérite pas autant de haine (personne ne le mérite d'ailleurs)) :

Oulala, il y a nul haine de ma part ni de quiconque ici d'ailleurs, enfin j'espère !
Ce sont justes quelques joutes plus ou moins humoristiques, des vannes ou des blagues parfois réussies, parfois moins et qui évidement peuvent plaire ou déplaire en fonction de qui les lit.
Il n'y aucune vendetta personnel
Comme je l'ai dit il y a longtemps (vu que tu es un patient interné récemment, tu l'as peut-être loupé), je n'aurai aucune réticence à discuter de tout ça bière à la main derrière un comptoir sans pour autant que ça se termine en pugilat. A limite si je fracassai ma chope sur Touko ce serait une fausse en sucre comme au cinéma

C'est d'ailleurs là que ton frére oiseau de proie, a pris ses infos [...]
Pour ceux que ça intéressent : http://wiki.neogeodev.org/index.php?title=Category:Video_system
Vous pourrez comparer avec le post du piaf .

Mes informations je les tiens d'un des rares développeurs Neogeo de la planète, sa page ici:
http://furrtek.free.fr/index.php?p=crea&a=neogeo&ng=1
qui n'est autre que l'auteur... du lien que tu pointes
D'ailleurs pour ceux qui sont réfractaires à l'anglais et qui s'intéressent un peu à la NeoGeo, je vous conseille de zieuter son site qui est très didacticiel.
C'est un franco-américain bien sympathique et si vous faites des conventions sur le retrogaming vous pourrez avoir la chance de le rencontrer, il était par exemple à la dernière RGC; convention annuelle que je conseille d'ailleurs à tous d'y faire un saut !
Enfin bref, digression mise à part, tu vois Touko la différence entre toi et moi c'est que mes infos viennent d'un développeur (qui bien sûr ne prétend pas avoir la science infuse et qui peut faire des erreurs) et toi, comme souvent, d'une fiche française de Wikipedia (ou de je ne sais quel site de fanboy) écrite et modifiable par n'importe qui et qui est bien sûr réputée comme tout sauf fiable.
Et ça n'a pas loupé, tu as relayé malgré toi les conneries habituelles qu'on peut lire autour de la NeoGeo dont les fameux background layer hardware qui bien sûr sont du pur fantasme.
Allez, fin définitif du HS !

Je m'excuse d'avoir été aussi long, mais il y a beaucoup à dire sur l'Amiga et sa passionnante histoire.

Ne t'excuses pas, il n'y a pas de règles préétablies pour la longueur d'un message et si la prose est bien écrite ça se passe tout seul.
J'aime bien tes proses d’ailleurs, elles ont un côté apaisant, surtout vu le capharnaüm qu'il y a dans ce topic :)


message édité 0 fois

[Lesarthois]

Furrtek développe pour la Neo Geo? Mais pourquoi il me l'a jamais dit ce salaud ? :lol:

Il fait plein de trucs et de bricolages, ce mec est un touche à tout incroyable.

[ArchieForEver]

ah tu vois archi la 3D te dépasse tu as du mal ..... ? (ah tu aimes le pré-calc :lol: ) tes progrès en 2D :lol: tu est a l'ouest total comparé au robocod sur archimèdes....

je t'ai dit d'aller faire un p'tit tour a 7' pour voir un plasma avec de la 3D, sur la démo archimèdes il n'y a pas de plasma avec un cube 3D, il ya juste de la 3D light source et de même a 10'15 pour voir un cube avec des animations vectorielle sur chaque face bien plus impressionnant techniquement que tous les effets de la demo archimède que tu ne cesses de montrer et même de la vector city :lol:


et pour le nombre de faces des objets 3d sur archi avec 4 mips (7 fois plus rapide qu'un 500) ce serait triste d'avoir des objets avec moins de faces qu'un st non ? (avec la puissance rien de plus facile par contre faire des prouesses techniques c'est autre chose...)
le nombre de dots de la démo archi est archi ridicule (héhé) comparé aux prods amiga tu ferais mieux de regarder les démos du mig qui ridiculise ton archimèdes ....

et t'en penses quoi de robocod , on peut prendre aussi lionheart, turrican 1,2,3, agony, leander, les beast.... la ou l'archi ne fera que regarder de loin les prods 2D de l'amiga...

et perso par rapport aux jeux de courses 3D sur achi

je préfère largement un indianapolis 500 sur mig (on a l'impression que l'archi est au ralenti a côté !!! regade stunt racer !! c'est quand même un jeu de courses de voitures .... ca doit aller vite non ? :lol: et le pc n'en parlons même pas en 1989 il est a l'ouest....)

je comprends mieux la durée de vie de l'archimèdes 3 ans (en angleterre), quand on voit les jeux sur ce support !!! même pas un beau jeu d'aventure en 256 couleurs c'est lamentable....

J'ai déjà répondu à toutes tes interrogations dans les discussions précédentes.

Tant mieux si tu préfères ton jeu sur 1/3 d'écran, aux couleurs ternes avec rendu de couleurs à la Spectrum, et aux graphismes grossiers.
Je garde le mien avec plaisir, sur 3/4 d'écran.

La durée de vie de l'Archimèdes en Angleterre, 3 ans ? Ha bon, première nouvelle.C'est à rajouter à l'affirmation de Touko que je n'aurais un 1200 que depuis 15 jours.
Bon, continues : j'adore voir mes opposants se ridiculiser.

Pour les jeux d'aventure on a eu sur Archie la série des Magnetic Scrolls, et quelques autres mais ça ne m'a jamais passionné.
Mais ce n'est pas l'objet de ce débat.
Qu'il y ait eu plein de softs sur Amiga ne changera rien aux qualités intrinsèques supérieures de l'Archimedes.

Les conversions ratées depuis le ST ou l'Amiga sur Archie parceque le budget était hyper serré, ça ne m'intéresse pas.
Dès qu'on fait un tour du côté des jeux développés en natif sur Archies l'Amiga peut aller se rhabiller.

Quand tu vois Lotus Turbo Challlenge identique sur Archie à la version Amiga, tu rigoles car sur Archie on a ça :


ou bien ça :



Un petit Wolfenstein pour le week end ?




Je pense que tu n'as jamais touché un Archie de ta vie, et ça me fait bien marrer.

[Invité]

Mes informations je les tiens d'un des rares développeurs Neogeo de la planète, sa page ici:
http://furrtek.free.fr/index.php?p=crea&a=neogeo&ng=1
qui n'est autre que l'auteur... du lien que tu pointes

Euh, je crois pas avoir dis le contraire justement puisque j'ai précisé que c'était là que tu avais tiré tes infos sur la NG, ça montre une fois de plus que tu lis pas correctement le piaf .
Le site que tu montres envoie vers le lien que j'ai posté qui est sa nouvelle page de référence .

Non, je suis peut être virulent surtout sur le piaf, mais aucune haine, je lui avait d'ailleurs déjà dit sur amiga vs ST ..

Sans rancunes le piaf , ou même archi

Pour les perfs des CPU amiga, la conception des machines donne la priorité des copros sur le CPU pour les accès à la chip ram, le CPU est la dernière roue du carrosse sur amiga .
Donc comme le CPU a des cycles limité pour l'accès à la chip, plus ton CPU est rapide plus tu perds de cycle CPU à attendre .
Evidemment l'ajout de fast corrige le problème, et tu peux dignement utiliser le CPU pour des calculs pendant que le copper et le blitter travaillent .
Et comme l'AGA n'est qu'une légère maj de l'ocs, les puces ne sont plus adaptées pour un 68020, et un système 32 bit .
Je pense que juste un blitter 32 bits et à la frequence du CPU aurai vraiment boosté les AGA, et ça coûtait pas grand choses.

Dans les derniers jeux, le copper est trop intensément utilisé pour palier les faiblesses de la machine en matière de sprites et de scrolling, ça bouffe quasi tout les cycles DMA .
J'avais posté un lien ou il est expliqué les astuces utilisées dans certains jeux comme brian the lion avec le copper .

Et comme le dit babsimov, la AAA devait faire partie de l'A1200, et là je peux te garantir, que même la NG aurai eu du soucis à se faire, mais bon c'est jamais sorti , et on à eu droit à l'AGA, un ecs 2, qui ne rivalise même pas avec une MD à cause de ses sprites merdiques .

[MikeeMike_2008]

tu as vu tes jeux de courses .... sans déconner c'est de la daube côté animations même un buggy boy est meilleur sur amiga !!!! (comparé a ton burn out)

et ton e-type2 regarde crazy cars 3 c'est le jour et la nuit a voir la maniabilité ca fait peur !!!





et au fait ton robocod sur archi .... tiens tu evites la question c'est bizarre hein :lol:

[65c02]

ArchiForever, ça te dirait de nous faire des tests sur Archimède et Amiga 1200 ?
Un truc qui m'intéresserait bien c'est que tu remplisse une zone mémoire assez grosse en mesurant le temps que ça prends.

Combien de temps il faut pour remplir 100 Ko avec le 68000
Combien de temps il faut pour remplir 100 Ko avec le ARM
Combien de temps il faut pour remplir 100 Ko avec le blitter de l'amiga
Combien de temps il faut pour remplir 100 Ko avec le DMA de l'archi.

Tu vois l'idée ?

Ça pourrait être pas mal comme tests et on sortirait des débats sans fin basés sur des spécifications sortie du net.

Pour mesurer le temps on peut juste changer la couleur du fond avant et après pour compter les raster lines. Pas besoin d'être super précis. C'est juste pour avoir un ordre de grandeur.

En tout cas ce topic est très intéressant (en plus d'être marrant :) ).

[Invité]

Tu peux pas faire ce type de comp, l'amiga c'est pas juste un blitter ou un copper, il faut prendre le tout, comme sur l'archi .

La question est de savoir si l'arm peu faire aussi bien ou mieux que l'amiga 500, et je peux sans soucis te dire que non .

Faut pas oublier que les demos makers de l'époque se battaient contre le ST, donc il n'ont pas poussé l'amiga dans ses limite .

Je pense que si l'archimede avait été dans la course, on aurai vu de bien belle choses encore .
Et l'ajout de fast ram, permet au 68000 de pouvoir s'exprimer pleinement, ce qui est loin d'être le cas qu'avec de la chip ram .

[65c02]

Sans être significatif c'est quand même un indice important

[ArchieForEver]

tu as vu tes jeux de courses .... sans déconner c'est de la daube côté animations même un buggy boy est meilleur sur amiga !!!! (comparé a ton burn out)

et ton e-type2 regarde crazy cars 3 c'est le jour et la nuit a voir la maniabilité ca fait peur !!!





et au fait ton robocod sur archi .... tiens tu evites la question c'est bizarre hein :lol:

Pas d'accord du tout, mais merci d'avoir posté ta vidéo, ça plussoit l'Archie encore une fois.
Oui j'ai répondu pour Robocod : ce n'est pas avec des conversions faites à la va vite depuis l'Amiga ou le ST que tu peux oser juger l'Archie.

[ArchieForEver]

Faut pas oublier que les demos makers de l'époque se battaient contre le ST, donc il n'ont pas poussé l'amiga dans ses limite .

.

??? Plaît-il ?

[ArchieForEver]

Sans être significatif c'est quand même un indice important

Tout à fait.
Je veux bien taper les routines pour vous donner les chiffres.

Mais heuuu... qui va faire ça pour l'Amiga ?
Pas Touko hein, ne me faites pas rire. Déjà il va avoir du boulot pour tenter de copier ma preview de démo sur PCE ...
Ah au fait Touko : ne te fatigue pas pour les graphs : pour les sphères raytracées j'accepte n'importe quel cercle que tu auras rempli de 256 couleurs, et pour le morceau de CD, prends n'importe quelle forme proche, toujours en 256 couleurs.

Pour le background du fond : pareil, des tiles en 256 couleurs quel que soit l'aspect, ça m'ira.
Tu penses pouvoir nous présenter les résultats quand ?
:pirat:

[Invité]

Pour ceux qui veulent des infos sup sur le blitter ,ça permettra par exemple à archi de dormir moins bête ce soir, surtout quand il croit que le DMA basique de l'archi, peut être comparé au blitter .

Archi arrêtes de parler 256 couleurs, j'afficherai plus de 256 couleurs à l'écran(proche de 300) point barre .
Y'a aucun exploit à animer des sprites en 256 couleurs vu que c'est natif sur l'archi .
C'est comme si je te demandais de faire des jeux en 4096 couleurs, pour égaler la NG .
Si tu me sorts un metal slug à l'indentique techniquement mais avec juste 60 couleurs, je vais pas chipoter.

Et tes bitmap pseudo raytracer, n'essayes pas de sous entendre que tu les fais en temps réel sur l'archi hein ..

Je précises, que tout tournera en 60 fps, avec plus de 256 couleurs à l'écran, par contre pas de scroll text, je passerai pas 3 plombes à faire des routines logicielles, j'ai pas le temps .
je remplacerai ça par des parallaxes sur le fond .
Rien que ça va me prendre ,aller 10 % de CPU à tout casser, sur une console 8 bit .

[kelter]

coool, j'ai hate de voir tout ca

[Invité]

Tu peux avoir un aperçu de ce que l'on peut facilement faire :


Evidemment ça tourne en 60 fps, les saccades ,c'est merci youtube.
Depuis j'ai tout amélioré, plus de parallaxes, plus de ralentissements lors du fade out lors de l'intro, et plus de sprites, et surtout, j'ai encore plein de cycles CPU en rab ..

[kelter]

L'anim du soleil est pas terrible lol mais comme tu dis faudrait voir en real play.

[Invité]

C'est à dire ??

Si tu parles des saccades, c'est normal, si je fais descendre le soleil à 60fps, le rendu est pourri,ca ira bcp trop vite, c'est pas un problème technique .

Et faut pas oublier que sa demo tourne sur une machine de 2 mo de ram, moi j'ai que 8 ko et 64 ko de vram .

[kelter]

c'est quoi comme resolution ?

[Invité]

Là, c'est du basique 256x224, mais on peut faire du 320x224 ou du 512x224 .

[kelter]

ok j'attends de voir le resultat final pour les 2 participants

super interessant.

Vous etes actifs dans un groupe de demo ? ou sur des développements de jeux ?

[Invité]

Moi pas de demo, je suis en train de faire un jeu style ik+/wotef, et le jeu billyboy pour l'assos retrotaku .

Et c'est pas une guerre de demo entre archi et moi, juste pour lui prouver que ça demo n'a rien d'extraordinaire en la faisant sur une machine 8 bit comme la pce, contrairement à ce qu'il prétend,c'est tout .

une bonne doc technique sur le hard de l'amiga (ocs) :
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0000.html

[kelter]

Au passage pour la video de crazy car 3, le gameplay de ce jeu est excelent je trouve, meme si techniquement il y a de gros defaut, n'oublions pas qu'on s'est me me amusé sur des jeux comme saboteur !!
Et le joueur de la demo est vraiment mauvais lol

[65c02]

Mais heuuu... qui va faire ça pour l'Amiga ?

Arf, vue comment tu nous parlais de ton amiga 1200 je pensais que tu avais codé dessus pour pouvoir comparer :p
Bah c'est pas grave, donne nous déjà les chiffres de ton test sur archi, on trouvera bien un amigaiste pour nous donner ceux de l'amiga :)

[ArchieForEver]

Pour ceux qui veulent des infos sup sur le blitter ,ça permettra par exemple à archi de dormir moins bête ce soir, surtout quand il croit que le DMA basique de l'archi, peut être comparé au blitter .
.

Bhouuu .. je n'ai jamais dit ça. Jamais.
Tu m'as juste dit que l'Amiga avait plein de DMA, je t'ai répondu qu'heureusement que pour la vidéo il en a au moins autant que de bitplans, et que, rien que sur ce plan là, l'Archie en aura moins puisqu'il n'en a besoin que d'UN pour sa mémoire vidéo 'chunky'.
C'est très différent, mais tu es de mauvaise foi.
D'ailleurs tu es bien incapable de répondre à ma dernière demande sur ce point précis des DMA.

[ArchieForEver]

Là, c'est du basique 256x224, mais on peut faire du 320x224 ou du 512x224 .

Ah oui je me disais aussi, c'est hypra moche.

Et bon Touko tu me feras la plaisir d'un petit scrolltext, c'est tellement basique pour toi, hein ?
Et que ça te bouffe bien une grosse partie de tes sprites hard disponibles, sinon la comparaison ne sera pas équitable.
Mais je sais que tu n'iras pas au bout, tu en es incapable et de mauvaise foi.

[Invité]

Tu continues avec cette histoire de DMA propre au type d'affichage .
Tu déconnes ,ça fait 150 fois que je te réponds, mais bon puisque je suis nul en explications, tu as tout ce qu'il faut savoir sur le blitter ici :

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0000.html

Par la même occasion, rends toi moins bête sur le copper, tu verras qu'il ne fait pas que de stupide changements de couleurs :
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0048.html

Et ne me dis pas que ça manque de précision ou que c'est du charabia .

Pour le scrolltext, ca sera pas un problème de nombre de sprites (j'en ai 64 de 32*64 pixels), mais juste le nombre par ligne, tu te doutes bien qu'avec les 3 gros sprites, je pourrai pas faire un scroll text en sprites, sauf sur sgx .
Ou alors, il faut que je reserve une bande style 16 pixels sur le bas ou les 3 sprites n'iront pas .
et là aucun problème, voire même ne pas utiliser de sprites du tout .
Donc il faut que je fasse une routine d'affichage en soft, et vu le nombre de cycle CPU qu'il me reste ça posera pas de problèmes .
Mais comme j'attends pas après toi pour bosser sur la PCE, j'ai pas le temps de m'amuser à ca .

[ArchieForEver]

Mais heuuu... qui va faire ça pour l'Amiga ?

Arf, vue comment tu nous parlais de ton amiga 1200 je pensais que tu avais codé dessus pour pouvoir comparer :p

Ah oui ? Tu as encore dû rêver. Où aurais-je laisser entendre que j'aie jamais programmé le 1200 ? J'ai dit que je trouvais cette machine fort sympathique, et bien plus intéressante que le 500.

On dirait du Touko : ça ressort régulièrment dans tous ses messages : prêter à ses contradicteurs des propos qu'ils n'ont jamais tenus, et ne jamais répondre vraiment à leurs propos.