[Vampire V4] Quelque chose de grand va être annoncé
-
Pour comparer avec les autres offres pour a1200:
ACA 1221 (68020 16Mhz 9Mo) 70 euro (pas dispo)
ACA 1221EC (68EC020 25Mhz 9Mo) 120-130 euro
ACA 1233n 68030 40Mhz 128Mo 240-270 euro
ACA 1232 68030 50Mhz 128Mo 380 euroQuand on rajoute tout ce que permet la v4 par rapport aux autres solutions pour accélérer un 1200 (IDE rapide, ks3.1, RTG, SAGA, AHI, 512Mo, …). Le prix de la v4 (un peu plus chère que la v2 a 370 euro) ne sera pas non plus un crime. C’est certain, ce n’est plus le prix de la première vampire (90e), mais ce n’est plus les mêmes caractéristiques.
Par contre le positionnement tarifaire prévu de l’autochtone, euh de l’autonome, bref de la standalone par rapport aux autres cartes à base de FPGA n’est pas concurrentielle. Pour qu’elle le devienne, elle devra faire plus que ces concurrentes. Pour le moment pour y arriver elle a l’exclusivité du 68080, du SAGA, de Pamela
Mod Pour le moment aucune carte standalone ne fait l aga complet et aucune solutiom ne propose qqc de plus complet que le tg68 + instruction 020 donc si simplement la team sort une carte qui fait un a1200 avec le 68080 se sera juste la 1ere machine complètement compatible 1200.
Car si je me trompe pas même le rpi n émule pas correctement le 1200
Dit comme ça, c’est un peu réducteur.
La carte mère v4 aura le processeur 68080 le plus compatible avec la gamme précédente, tout en offrant une architecture 64 bits, de nouveaux registres et une panoplie de nouvelles instructions (je dis « aura » mais c’est en fait déjà le cas). C’est un bond en avant de plus de 20 ans contrairement à toutes les implémentations 68k existantes sur fpga.
Le Core SAGA sera le plus compatible avec l’AGA (en tout cas c’est bien parti pour), et il offre déjà, encore une fois, un bond en avant de plus de 20 ans pour les capacités RTG. Je rappelle encore une fois que ce qui faisait les caractéristiques de l’amiga (blitter, copper, paula, entre autres), fonctionnent en harmonie avec les nouvelles fonctionnalités. On a donc un copper qui manipule du RTG, du Pamela (version supérieure de Paula) ou du blitter, contrairement aux « anciennes » solutions dans le pur style PC: carte gfx, carte son.
Enfin, l’équipe Vampire/Apollo suit à 100% la philosophie Amiga en offrant des cartes complètes, donc pas livrées en kit comme sur PC, ce qui fait qu’on aura exactement les mêmes perfs partout. Donc, même principe que les consoles de jeux.
C’est une situation idéale pour un développeur qui veut exploiter au mieux une config. Il sait qu’il n’aura pas à faire d’exception ou de compromis sur un code. On peut régler n’importe quelle routine au cycle près en sachant que ça tournera de la même façon partout, et que ça touchera toutes les gammes amiga possibles (celles équipées en vampire).
Les gens qui veulent pouvoir mettre la quantité de ram qu’ils veulent, de n’importe quelle marque qu’ils veulent, ne se rendent pas compte comment ils brideront le raisonnement des développeurs derrière.
Ces choix n’auront d’impact positif que si les cartes font un carton.
Les mêmes perfs (élevées) partout c’est vraiment un point intéressant. Si de nouveaux développements se font, ils marcheront partout pareil. Le A500 ou le A1200 auront la même puissance. Les deux seront capables de fps élevés tout en affichant pleins de couleurs et un son 16bits. C’est un grand retour de la grande époque amiga où les 500 et les 2000 de base faisaient tourner les mêmes jeux. Un seul programme touchait 100% des utilisateurs sans ségrégation. C’est bien ca.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)J’aimerai aussi rebondir sur les gens qui disent un truc du style « super, ceux qui viennent d’acheter la v2 sont les premiers baisés ».
Bon là, sachant qu’on vit dans le même monde, on peut être un peu circonspect. Difficile de comprendre le fond du problème vu que c’est le même principe partout ailleurs. C’est même pas une question de business pour l’équipe Vampire. En fait, c’est une problématique systémique.
Si la V1 ne s’était pas vendue, il n’y aurait peut-être pas eu de V2. Si la V2 ne s’était pas vendue, il n’y aurait probablement pas eu de V4, etc.
De plus, le progrès fait que les composants s’améliorent et les prix baissent. En l’occurrence, les fpga non abordables hier, sont plus abordables aujourd’hui. Et là, je vais donner un scoop mais vous le gardez pour vous: si la v4 se vend bien, il est possible qu’une v5 sorte d’ici 1 an ou 2 avec un plus gros fpga. Mais attention, à ne pas le répéter à gauche ou à droite; cela doit rester secret. Donc, n’achetez pas la v4 car la v5 sortira d’ici 2 ans. Nonobstant, si la v4 ne se vend pas, il est possible que la v5 ne sorte pas… et merde…
Je poursuis le raisonnement: L’idéal serait donc d’acheter le dernier modèle juste avant que le fabricant en question, coule pour des raisons économiques. En gros, c’est comme acheter le dernier A1200 en sachant que commodore est mort et que c’est la fin économique du produit… Dis comme ça, c’est pas non plus la solution.
Moi, à chaque fois que j’achète un disque dur, un téléphone portable, une télévision HD ou n’importe quoi d’autre, je devrai me dire 6 mois après (ouais, c’est moins d’un an chez les autres): « put*in, je me suis fait baiser ». Du coup, on est pas loin d’1 milliard de cocus dans l’histoire.
Je le répète, c’est un phénomène systémique lié à notre mode d’économie et au progrès qui en découle. L’équipe Vampire/Apollo est bien incapable de planifier ce genre de plan machiavélique puisqu’ils n’en font pas un business.
Est-ce que la vampire peut afficher l’ECS sur des Amigas OCS ?
Afficher ECS ? ECS et OCS ont strictement les mêmes affichages. Seule change la quantité de chip-ram adressable et un blitter capable de traiter des blocs plus gros (et l’affichage des sprites dans les bordures d’écran). Mais question affichage c’est la même chose entre OCS et ECS.
Donc comme la vampire a 4Mo de chip, elle affiche tout ce que les anciennes machines peuvent afficher et même plus. Sauf qu’elle affiche par HDMI et ca c’est super vu que les TV modernes n’ont plus de peritel.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)Je fais suivre ici des informations de Gunnar sur l’apollo core, pour ceux qui découvrent le projet:
Le 68080 offre 16 registres d’adresse (8 sur 68060 et en dessous):
Donc A0-A7 pour les registres d’origine, et B0-B7 pour les nouveaux registres.Il offre 32 registres de donnée pour les opérations logiques et arithmétiques (8 seulement sur 68060 et en dessous):
Donc D0-D7 pour les registres d’origine, et E0-E23 pour les nouveaux registres.Tous ces registres sont 64 bits.
(Perso, je ne sais pas pourquoi il les nomme pas A0-A15 et D0-D31. Ce serait bien que Guybrush, Tuko et Flype nous fassent un petit retour sur la question, eux qui sont en bonne relation avec les autres membres de la team). [ndseg: j’insiste volontairement sur Guybrush ;)]
Les instructions AMMX et toutes les anciennes instructions peuvent utiliser ces registres anciens et nouveaux.
Les instructions AMMX sont juste des instructions 68k normales. Vous pouvez mixer chacune d’elle avec n’importe quelle autre instruction.
Et donc, en clair, les instructions AMMX et les anciennes utilisent les mêmes registres.
Ceci étant un résumé reformulé, les informations originales sont à lire ici.
A ma connaissance, seul l’assembleur vasm sait gérer en natif les nouveautés du 68080. Pour les autres assembleurs, il faudra passer par des macros.
J’ajoute d’autres informations qui me viennent en vrac et qui ont déjà été données antérieurement:
– pas de soucis d’alignement 32 bits ou 64 bits pour les instructions, et pas de pénalité de cycle comme le 060 en cas de mauvais alignement
– le 68080 supporte le code auto modifié comme sur 68000.
– il intègre également les instructions 64 bits qui avaient été retirées du 060 (mul.l et div.l entre autres).
– Le 68080 de la V4 va être encore plus gavé en cache
Il y a sûrement d’autres choses à dire mais j’ai plus le temps. a+
A noter à propos des registres en plus E0-E23 et B0-B7, l’OS amiga non modifié ne les préserve pas lors des changements de contexte. Donc Si 2 taches les utilisent, il se peut que leur contenu soit modifié par l’autre tache. Ca conduit à des instabilités.
Je ne sais pas si l’OS livré avec les vampire s’occupe de ce problème car c’est vraiment pas simple puisque cela modifie l’organisation mémoire de la pile (les setjmp/longjmp du C ne marcheront plus correctement). Je ne serais pas surpris que pour le moment l’OS ne s’occupe pas de ces nouveaux registres et ne gère que les anciens Dx et Ax.
Ca expliquerait aussi peut-être pourquoi Gunnar sépare clairement les Dx/Ax des Ey/By: l’OS ne s’occupe que des Dx et Ax, les Ey et By sont à la charge du codeur (une seule tache à la fois peut les utiliser en cas de multitâche: le codeur donc faire un Disable()/Enable() autour des zones critiques utilisant ces nouveaux registres).
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
L’os livré avec ? Os3.1 modifié, aros ?, autre ?
Only amiga makes it possible
XTR Games
Magic Productions
tildeOS3.1 modifié bien entendu. Mais de ce que j’ai pu lire, quand on utilise les registres 64bits (mode AMMX), il faut placer un bit à 1 dans le SR, ce qui modifie la sauvegarde des registres sur pile lors des interruptions, et donc lors des changements de contextes. Ce qui veut dire qu’à ce moment là les valeurs 64bits sont bien préservées automatiquement. Si c’est bien ca, ca veut dire que leur choix technique est pas con du tout quand ils sont combinés au fonctionnement de l’amiga OS. Ca c’est carrément génial!
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
Certains vont peut-être hurler mais sait-on ce que pense l’équipe de MorphOs de la Vampire ?
Pas intéressée.
Attendre et voir…
Jamais de la vie !
Hein, où ça un vampire ? 😉
PowerMac - G5 2.0 GHz - 1.7 Go RAM - Radeon 9600P 128 Mo - MorphOs 3.13 et Peg2 - G4 RIP
Mac mini - G4 1.42 GHz - 1 Go RAM - Radeon 9200 32 Mo - MorphOs 3.9
WinUAE sur HP Core2 Quad 8200
Epave de Mist FPGA remplacé par un Sidi
A1200 malade 😉 et A500 512+512Ko RAM Kickstart 1.3@__sam__
Oui, il reste la problématique du changement de contexte où il faut sauvegarder les registres en 64 bits ainsi que les nouveaux registres.
Je pense que ce n’est pas un problème de modifier l’OS pour ça. D’ailleurs, l’OS a le même problème quand un fpu est détecté. Il empile et dépile les registres FPx en plus des registres Dx.
Il faut ensuite gonfler les piles des applications pour pas que ça plante.
Par contre, moi j’utilise executive comme scheduler. Je sais pas comment ce truc est intégré au système natif?
@logo MorphO-Quoi ? 😀
Je crois que de chaque coté ils s’ignorent. L’un est un OS PPC, l’autre une carte accélératrice 68k. Ca ne fait pas vraiment de point communs. En revanche OS4 est possible si l’on croit à cette blague du 1er avril: http://www.apollo-core.com/knowledge.php?b=1¬e=4533
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › [Vampire V4] Quelque chose de grand va être annoncé
