Pour ma part, ça fait longtemps que je ne me suis pas occupé de la carte Vampire V2 par manque de temps, mais je peux quand même apporter quelques réponses.
Rajah (./2) :
Bizarre de voir le GEM tourner sans faille sur du matos Amiga,
Eh oui, à partir du moment où la machine a un CPU compatible, et où les programmes utilisent proprement l'OS (pas d'accès direct au hardware), tout marche nickel.
Rajah (./2) :
Les modes vidéos proposés sont assez larges, résolutions étendues (ici écran 16/9 en TC16) comme celles d'origine.
A ce jour les seuls modes graphiques disponibles sur Vampire sont fournis par mon driver SAGA.SYS pour fVDI. Il supporte un nombre limité de résolutions 4/3, 16/9 et 16/10. Seuls les modes 16-bit 65536 couleurs sont supportés pour l'instant. La raison : ce driver est une adaptation de l'exemple de driver 16-bit pour Falcon fourni par fVDI. Et j'ai eu la flemme de m'atteler aux autres modes.
Attention : Gardez bien en tête que ce driver est juste une preuve de concept (réussie !), il n'est absolument pas optimisé.
Rajah (./2) :
Sinon, petit narcissisme du quotidien, j'ai demandé un essai de mon portage de Xenon2 sous GEM : c'est lent. La FireBee est plus rapide. Mais je crois que cela pourrait être plus rapide avec une optimisation du driver VDI vis-à-vis de la vidéo de la Vampire (nommé SAGA), ou de l'utilisation de NVDI ?
Sur FireBee, le driver graphique a été optimisé par Didier Méquignon. Quant à NVDI, je ne sais pas s'il accélère l'affichage sur cette machine.
Comme je viens de le dire, mon driver SAGA.SYS pour Vampire V2 n'est pas spécialement optimisé. Donc n'espérez pas de grosses perfs avec les benchmarks graphiques. En revanche, les autres benchs (CPU, RAM) sont significatifs.
Rajah (./2) :
Quid de la présence de la Fast/TT-RAM ?
La carte Vampire V2 est équipée de 128 Mo de FastRAM qui est très rapide. EmuTOS et FreeMiNT l'utilisent de manière optimale.
En revanche, sur Amiga la Chip RAM (équivalent ST-RAM) est très lente, même avec une carte Vampire. Donc si un programme Atari utilise uniquement la ST-RAM, il aura des perfs relativement faibles sur Vampire. Mais s'il utilise la FastRAM, il boostera autant que possible.
Rajah (./2) :
Mon code est en GFA-68000 et VDI purs, donc c'est pas un gage de rapidité.
Le 68080 est très performant pour exécuter les instructions 68000. Dans le cas d'un jeu, l'affichage consomme beaucoup de CPU, donc l'optimisation du driver graphique est de première importance. Donc il y a fort à parier que les lenteurs viennent du driver fVDI. Quoi qu'il en soit, pour optimiser un programme, il faut utiliser un profiler pour déterminer les fonctions qui rament. Sinon on fait des suppositions à l'aveuglette.
Rajah (./2) :
Doom recompilé semble-t-il pour 68080 dépotait, plus rapide que FireBee (moins que la version Jaguar cependant).
Le 68080 émule un 68040 (et aussi les instructions des autres processeurs, autant que possible). A ma connaissance il n'existe pas de compilateur qui utilise les nouvelles instructions spécifiques au 68080. Certains programmes Amiga ont été manuellement patchés en assembleur pour exploiter les instructions spécifiques 68080 (principalement AMMX).
Concernant PmDoom, j'ai testé la version 68000 sur Vampire, et en effet, ça tourne très bien dans une petite fenêtre GEM.
Je ne pense pas qu'il existe de version spécifique 68080.
Personnellement, je trouve que le 68080 est super, ça tourne vraiment bien sur Amiga avec une carte Vampire. La compatibilité Atari est très limitée puisqu'il n'y a pas de hardware Atari sur une telle machine, mais pour les applis purement GEM ça marche vraiment très bien.
Si un jour il existe un Atari avec processeur 68080, alors ce sera super car il aura à la fois la compatibilité hardware et un CPU rapide compatible 68040.
Tophe38 (./3) :
Alors, ok, il faudrait que je jette un coup d’œil à Emutos, car, la dernière fois que j'avais regardé ça, je n'avais pas trouvé ça utilisable (plantage quasi constant).
Franchement, EmuTOS marche bien. Tous les bugs rapportés sont méticuleusement étudiés et corrigés.
En revanche, il y a des applications incompatibles, pour diverses raisons.
Si tu as des exemples concrets de "plantages quasi constants", sois sûr que l'équipe de développement d'EmuTOS fournira des explications, et corrigera EmuTOS s'il est en cause.
Vincent Rivière