Infos sur la Vampire
-
oui, désolé pour la qualité, on avait pas pensé à prendre des micros, et le smartphone montre ses limites. On fera mieux à la prochaine présentation.
Pour Akiko, non il n’est pas implémenté.
Petite question :
J’ai une V600 v2 et une V500 v2+, lorsque je connecte mon HxC floppy emulator (Lotharek ) sur l’un des mes Amigas vampirisés et que je boote la machine pour lancer le workbench sur le HD, j’ai le message « Please insert volume DF0 in any drive », je ne sais pas pourquoi?
Si ensuite je fais un simple reset, je n’ai plus le message et le floppy emulator fonctionne normalement.
Il y a des utilisateurs de Vampire et de Floppy emulator qui ont déjà constaté cela ?
L’excellentissime Formula One Grand Prix:
https://www.youtube.com/watch?v=oYxEFUgWe1o&feature=youtu.be
mmm…. désolé, je n’ai pas de HxC pour tester. C’est sur la v500 et sur la v600 aussi, ou seulement sur une des deux machines ?
C’est sur les deux, ce qui me rassure quand même sur l’état des vampires, dont le hardware ne doit pas être en cause.
le HxC fonctionne aussi très bien en temps normal.
Des news de Gunnar:
« L’Apollo 68080 à maintenant l’hyper threading activé.
Il s’agit d’une amélioration majeure pour la communauté 68k.
Les logiciels en tirant bénéfice sont développés à l’heure actuelle. »Merci seg pour l’info.
petite question : combien de chips est prévue pour là vampire ?
je ne comprends pas ta question, tu veux dire de chips physiques pour la V4 ? Ou la mémoire CHIP ?
Je pense qu’il veut parler de la mémoire.
Faut oublier chip et fast. Maintenant c’est que de la chip en vitesse fast (version de nos jours). Donc, pour la vampire, 128M de chip équivalent à de la fast moderne.
[EDIT]
Sinon, pour tout ce qui est son (Pamela maintenant) et gfx, les chips peuvent adresser la totalité de la mémoire.
En revanche, il faudra certainement prévoir de laisser un peu de chip originale pour avoir un lecteur de disquette fonctionnel, car le contrôleur ne peut être court-circuité par le core SAGA. Où alors il faut prévoir un contrôleur et une sortie câble directe sur la vampire (forcément une autre).
Sinon, pour comprendre ce qu’est l’hyper threading, il s’agit en fait de la première approche d’un cpu à 2 cœurs. En l’occurrence ici, pour l’utilisateur, c’est comme s’il avait un dual core mais avec 2 cœurs gérés virtuellement en hardware.
Les 2 cœurs partagent le même cache et le même bus mais avec des registres différents. Le cpu se charge d’optimiser sa logique d’exécution selon les threads utilisés.
Bien sûr, l’hyper threading n’a aucune utilité sur l’amiga os actuel. En revanche Aros serait en avance là-dessus.
Je pense qu’il veut parler de la mémoire. Faut oublier chip et fast. Maintenant c’est que de la chip en vitesse fast (version de nos jours). Donc, pour la vampire, 128M de chip équivalent à de la fast moderne.
Mmmm…. bien que ce que tu décrives soit possible, ce n’est pas de cette manière que fonctionnent nos core de test actuellement. Maintenant, nous avons 4 MB de chip (on le voit sur mes vidéos), qui sont donc bien entendu retirés des 128 MB, et la mémoire restante est de la FAST. Mais il serait tout à fait envisageable de faire comme tu le décris.
Sinon, pour tout ce qui est son (Pamela maintenant) et gfx, les chips peuvent adresser la totalité de la mémoire. En revanche, il faudra certainement prévoir de laisser un peu de chip originale pour avoir un lecteur de disquette fonctionnel, car le contrôleur ne peut être court-circuité par le core SAGA. Où alors il faut prévoir un contrôleur et une sortie câble directe sur la vampire (forcément une autre).
oui, effectivement, on est obligé de garder de la chip.
Bien sûr, l’hyper threading n’a aucune utilité sur l’amiga os actuel. En revanche Aros serait en avance là-dessus.
Pour l’OS en lui-même, oui effectivement, mais il y a pleins d’autres manières d’utiliser le multi threading et d’en faire bénéficier notre OS : on peut s’en servir pour réduire la latence et décongestionner les IRQ. Du coup, les drivers spécifiques peuvent profiter de l’hyper threading, et donc profiter d’un gain substanciel de performances. Au final, on a un OS plus rapide tout de même, même si ce sont seulement les drivers qui sont accélérés.
Exemple :
Si on prend le cas d’un driver IDE qui fonctionne en parallele avec une application : sans hyper threading, il va faire énormément d’appels IRQ. Chaque appel passe par la couche IRQ de l’OS, tout les registres sont sauvegardés, le driver fait son job, puis les registres sont restaurés. Avec l’hyper threading, un driver qui est écrit pour en tirer partie va utiliser les registres supplémentaires mis à dispositions (registres qui ne sont pas vu par l’OS mais que par les soft développés pour en tenir compte, dont notre fameux driver) pour stocker et restaurer ses registres, donc il ne passe pas par L’OS. Donc, gain de performances pour l’autre programme qui est toujours en train de fonctionner. On peut voir ça à titre d’explication comme la présence du PowerPC sur la Blizzard/cyberstorm PPC, le problème de context switching en moins : les programmes purement 68k ne savent même pas ce qu’est un powerpc et ne le voient pas du tout. Les programmes écrit pour en revanche peuvent en tirer partit.
Je trouve que c’est une approche assez intéressante, car elle va permettre des gains de performances principalement dans l’usage multitâches.
BigGun le décrit bien mieux que moi sur ce fil :
http://www.apollo-core.com/knowledge.php?b=1¬e=6668&z=XycwFT
ce n’est pas à proprement parlé un 2ème CPU, seul une petite partie est répliquée (registres, pipeline et IRQ principalement) :
et en l’occurence, l’occupation est très faible, c’est une des raison principale pour laquelle ça a été fait.
- Le sujet ‘Infos sur la Vampire’ est fermé à de nouvelles réponses.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire
