1

Bonjour,

quelqu'un a t'il été à la microalchimie et aurait des nouvelles / informations à donner à propos de vampire?

Merci

Olivier

2

J'étais dans l'équipe organisatrice, donc très peu de temps pour profiter de la party. Ai pu néanmoins prendre 15 minutes pour voir la version Atari du système Vampire. Un Amiga 600 en boitier plexi transparent avec la fameuse carte (V2) bien visible, un appui sur le bouton joystick au moment de la mise sous tension et ça boote sur EmuTOS. On arrive sur MiNT/XaAES avec le pack Bee de Philippe Noble (personnalisé ?). Bizarre de voir le GEM tourner sans faille sur du matos Amiga, je lorgne plus du côté de la version V4 standalone.
Les modes vidéos proposés sont assez larges, résolutions étendues (ici écran 16/9 en TC16) comme celles d'origine. La compatibilité low tech pourrait être assurée.

Anecdote racontée par Guibrush : les ataristes (dont Vincent Rivière) impliqués dans le projet de la V4 ont contribué à débloquer le développement.

Ne suivant pas de près le projet, suis dans l'incapacité de répondre à ta question. Faites pas vos mijaurées, faut viendre à la µAlchimie ou à l'Alchimie (l'an passé, ou la prochaine en novembre 2019) : https://www.triplea.fr

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 ? Quid de la présence de la Fast/TT-RAM ? Mon code est en GFA-68000 et VDI purs, donc c'est pas un gage de rapidité.
Doom recompilé semble-t-il pour 68080 dépotait, plus rapide que FireBee (moins que la version Jaguar cependant). Donc autant comparer choux et poireaux. Kronos était présent pour comparer les "appareils" (pomme OpenGL rapide), c'est bon pour la promotion et se toucher la nouille, mais ne présage pas du quotidien avec ce nouveau matériel.

Verdict provisoire : du très beau travail, un projet excitant avec une équipe motivée, et déjà du concret. Par contre, d'expérience, j'ai l'impression que la majorité de la tribu atari préfère le low tech et le gratuit.

3

Hello,

Merci pour ce retour intéressant.

Si un Atari se résume a Emutos, et bien, je n'ai rien compris aux machines Atari.
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).

Concernant le projet vampire, les concepteurs s’éclatent bien, et c'est tant mieux.
Maintenant, reste la question du prix. Les modèles en vente actuellement sont autour de 350€, et la prochaine itération ne devrait pas être moins chère (sauf miracle).

La communauté Amiga semble particulièrement riche, beaucoup n'hésitent pas à acheter les boîtiers et touches franchement hors de prix, et sont prêt à mettre encore plus dans une carte pour jouer à des émulateurs et regarder une vidéo.
Pour 50€, un raspberry fait la même chose.

J'adore mes Atari, et mes Amiga, j'adore utiliser et entretenir ces machines, et même les upgrader. Mais j'ai quand même des limites financières (je n'habite pas en Suisses, même si je ne suis pas loin).
Appels ça du "low tech et gratuit", personnellement j'appelle ça avoir les pieds sur terre.
Il y a aussi des possesseurs d'Amiga qui pense la même chose, mais le débat sur cette carte n'est absolument pas possible.

A l'origine, la carte Vampire se voulait une alternative bon marché aux cartes existantes. J'ai eut une V1 pour 90€.

Il s'agit d'un avis personnel, évidement...
Tophe

4

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
avatar
Abonnez-vous à ma chaîne Vretrocomputing sur YouTube et Facebook. Dernière vidéo : Désactiver le bip clavier en assembleur sur Atari ST.

5

@BlankVector: merci pour les rectifications.

Concernant la vidéo, la liste des modes rapidement proposés au boot était assez large, ça m'a donné la fausse impression que l'éventail de résolutions incluait les modes ST.

Pour la différence de vitesse avec FireBee, pas besoin de supposer : mes jeux utilisent une tonne de vro_cpyfm pour les sprites et vrt_cpyfm pour les masques afin de calculer chaque image. Alors que pmDoom calcule sa scène pseudo3D en interne. Donc effectivement il y aurait du gain à peaufiner le driver fVDI pour SAGA.

Une chose que j'ai oublié de mentionner pour la Vampire/Atari : pas encore de son (ni dma, ni ym).

@Tophe38:

Pour EmuTOS, c'est une solution viable et obligatoire pour ne pas être embêté si Atari réclame ses droits sur le TOS. Avec MiNT et XaAES, on l'oublie facilement (cf solution sous Aranym). Seul, EmuTOS est OK, mais j'ai du mal avec l'interface du bureau. Il est par contre très bon pour les tests de mes softs, car beaucoup moins tolérant aux bogues des applications mal codées que le TOS d'Atari.

Je te rassure, beaucoup de la tribu Atari fonctionne comme toi. Mais je ne crois pas que tu suives de près l'actualité Amiga. Pour te cultiver, il y a le podcast d'AmigaImpact qui est de retour et assez régulier maintenant. Avec des infos Vampire inside.

6

Rajah (./5) :
obligatoire pour ne pas être embêté si Atari réclame ses droits sur le TOS.
Sachant que cette probabilité est quasi-nulle (contrairement à ce qui se passe côté Amiga), quand même.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7

Rajah (./5) :
Concernant la vidéo, la liste des modes rapidement proposés au boot était assez large, ça m'a donné la fausse impression que l'éventail de résolutions incluait les modes ST.
Pour configurer la résolution avec mon driver fVDI, il faut manuellement éditer le fichier FVDI.SYS avec un éditeur de texte. Je ne connais pas ce menu.

Mais ça fait très longtemps que je n'ai pas testé les nouveautés du core Vampire. Il y a déjà de longs mois (si c'est pas l'an dernier), l'Apollo Team a ajouté le support des modes vidéo ST. Ca permettra de grandement améliorer la compatibilité avec les logiciels qui utilisent directement le Shifter. Mais pour cela, il faut que je modifie EmuTOS et/ou le driver fVDI, et je n'ai pas pris le temps de le faire. Ce menu fait très certainement partie de ces évolutions que je n'ai pas encore testées.
avatar
Abonnez-vous à ma chaîne Vretrocomputing sur YouTube et Facebook. Dernière vidéo : Désactiver le bip clavier en assembleur sur Atari ST.

8

Merci de ces informations.

Pour la VDI les copies de blocs ne sont absolument pas optimisés des tests sous Kronos l'ont parfaitement montrés il y a quelques mois mais bon si cela marche le plus gros est là, si j'avais une carte standalone capable de faire fonctionner en gros la bête, j'y passerais bien quelques moments, l'optimisation c'est sensiblement plus simple que de tout écrire d'une page blanche, merci Vincent. Je me rappelle la lenteur de la vidéo sur la carte d'évaluation coldfire quand Didier m'envoyait ses première versions fonctionnelles, après quelques jours et pas mal de lancement de Kronos par Didier, la différence était furieuse plus du tout la même machine, la vidéo cela fait presque tout.

Hard vs émulation, c'est une vieille histoire, ce n'est sans doute pas forcément rationnel, pour moi qui vient de passer plus de 20 ans en émulation, le hard cela me tente, même si c'est pour faire tourner les softs qui existent l'intérêt me semble limité, mais pour les bricoleurs, ceux qui ont rêvés d'un 68000 moderne, qui veulent taper directement dans le hard ou qui aiment l'assembleur cela semble pouvoir être intéressant, l'informatique aujourd'hui de plus en plus stéréotypé laisse pas mal de l'aventure qui a présidé à son essor.

Cela n'arrive pas encore correctement au bureau mais cela n'est pas bien loin:



Je pensais venir mais bon problème perso j'ai renoncé, peut être l'année prochaine, si j'ai acheté une V4 standalone et que Emutos marche dessus, promis je viens avec.

Olivier

9

Hello Tous,

Merci pour vos retourset vos corrections.
Je vais revoir multitos et tout le travail qui est fait autour.
Mes infos datent en peu (voir beaucoup), donc, je serais ravi de revoir mon jugement chinois.

Amicalement,
Tophe

10

avatar
Atari Falcon030, Milan 040
avatar téléchargé sur www.sevenoaksart.co.uk

11

Impressionnant de voir fonctionner FreeMint dessus eek top
avatar

12

Je trouve cela super aussi

Olivier

13

avatar
Atari Falcon030, Milan 040
avatar téléchargé sur www.sevenoaksart.co.uk

14

Ça carbure, reste à améliorer la VDI pour palier la contre performance en blitting.

Olivier, à quoi correspond le test Blitting ? uniquement une série de Vr?_cpyfm() ?
avatar

15

Bonjour ,

Effectivement il y a 3 vro_cpyfm dans le test, de la mémoire centrale à l'écran, de l'écran à la mémoire et de l'écran à l'écran.

le Vro_cpyfm() de Emutos est particulièrement lent car il applique le masque même pour la copie donc il fait le boulot 2 fois!

Olivier

16

Dommage, le mode copie (3) devrait être dans une fonction à part, voir les mode 2 et 7 qui sont les plus utilisés (afin d'être optimisé).

Cela explique aussi la faible perf du Video Move.
avatar

17

OL (./15) :
le Vro_cpyfm() de Emutos est particulièrement lent car il applique le masque même pour la copie donc il fait le boulot 2 fois!
Tu parles de la fonction vro_cpyfm() de la VDI interne d'EmuTOS, ou du driver fVDI en couleurs qu'on voit dans la vidéo ?
avatar
Abonnez-vous à ma chaîne Vretrocomputing sur YouTube et Facebook. Dernière vidéo : Désactiver le bip clavier en assembleur sur Atari ST.

18

BlankVector (./17) :
OL (./15) :
le Vro_cpyfm() de Emutos est particulièrement lent car il applique le masque même pour la copie donc il fait le boulot 2 fois!
Tu parles de la fonction vro_cpyfm() de la VDI interne d'EmuTOS, ou du driver fVDI en couleurs qu'on voit dans la vidéo ?

oups autant pour moi je n'avais pas vu qu'ils étaient passés à fVDI dans la vidéo, je n'avais pas regardé la vidéo (j'ai une connexion internet médiocre en ce moment je me connecte sur un hotspot un peu loins, je n'ai pas encore d'abonnement depuis mon changement de lieu d'habitation)

En fait le blitting est rapide de l'écran à la mémoire et de la mémoire à l'écran ce qui doit bien représenter 95% de l'utilisation courante du vro_cpyfm je pense, il n'y a qu'un cas assez curieux c'est quand il y a copie de l'écran vers l'écran ce qui est ma fois très curieux dans le cas de la V4 je ne vois pas pourquoi c'est la même chose que de copier d'écran à mémoire. Mais en fait je n'ai pas les valeurs de débit et les comparaisons peuvent être trompeuses en % parce que je pense que la comparaison est avec supervidel, il n'y aurait pas en hard la copie de blocs de mémoire écran à mémoire écran?

Olivier

19

Je vous conseil de jeter un petit coup d'oeil sur les derniers benchs de la V4, les copies de blocs (vro_cpyfm) ca décoiffe avec un petit peu d'assembleur mis dans le driver!

Monstrueux!

http://www.apollo-core.com/knowledge.php?b=2&note=20382

20

Mmmm... les performances VDI n'ont pas changé hum

La fréquence du 080 n'est pas mentionné, on ne sait pas si c'est une amélioration du CPU seul ou avec une monté en fréquence.

The VDI driver was so far optimized with some handwritten 68K ASM.
The driver is not yet optimized with AMMX. (this is todo)
The V4 68080 CPU and Cache controller also boosts the speed somewhat.


processeur: (1)132 -> 162(2) +23%
fpu: 127 -> 153 +21%
memory & video bus: 513 -> 809 +58%
vdi: 138 -> 138 +0%
opengl: 94 -> 126 +31%

(1). 17 mars 2019
(2). 26 avril 2019


Mais quel progression, bravo top
avatar

21

Bonjour

J'ai reçu les résultats Kronos du dernier core x14 (ce qui fait une fréquence à 99Mhz) de la V4, pour l'instant j'ai regardé en gros les résultats, je me suis attardé au test opengl
Pour le test il a été choisi le mode 68040 perso je pense que le mode 68881 si il fonctionne devrait donner de meilleurs résultats. Si je compare avec une CT60 très bien configurée à 100Mhz c'est 17% plus rapide.

Olivier

22

Bonjour,

En fait le cas le plus mauvais est celui indiqué ci dessus dans bien d'autres cas c'est bien meilleur et le fait de ne pas être une carte accélératrice pour la version "standalone" permet d'avoir accés à la STRam et à la mémoire vidéo à la même vitesse que la TTRam !
Voici la page principale de comparaison de Kronos, avec comme référence la V4 comparé à la CT60 et firebee (dans ce cas le bench date je ne sais pas si il y a eu du progrès depuis) ces 2 composants sans carte vidéo additionnelle. J'ai préparé une comparaison détaillée je la proposerais sous peu.

XMz3

Olivier

23

Est-ce que le code source de kronos est dispo, et si oui, est-ce qu'il est possible/facile de le faire fonctionner sans OS compatible TOS ?
avatar

24

Kronos est du pure GEM et certains tests sont en assembleur donc pas possible

25

Détails et explications : http://kronos.lutece.net/V4/V4_comparison.pdf

Olivier