Vampire et Phoenix Core
-
@receptor: Aie j’ai mal aux yeux. Ca piiiiiique! Il faut prévenir quand on poste ca, il pourrait y avoir des morts.
@seg t’as raison 😛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.)@flype : tu pourrais modifier deux trois trucs dans ton code pour voir l’impact de la séparation des bus instruction et data ?
dans la fonction FireUpdate il suffirait d’alterner les clr.l et les move.b, du genre
[code]
.loopX
clr.l d2
move.b -1(a0),d2
clr.l d3
move.b 1(a0),d3
…
[/code]tu dois pouvoir faire le même genre de modif dans la fonction FireDraw.
Tu devrais gagner quelques fps encore.
Bonne journée
EDIT : je viens de voir que Gunnar te filait déjà quelques tuyau pour la fonction.
le pilote picasso 96 pour la v2 600 est sorti pour les possesseurs de la carte
Dans Prefs-> ScreenMode sélectionner Vampire 640×480 16 bits et cliquez UTILISATION, rappelez-vous ne cliquez pas sur Enregistrer puisque vous pourriez avoir des problèmes plus tard et vous serez obligé de le récupérer à l’état précédent de la CLI.
lien du sujet
http://www.apollo-core.com/knowledge.php?b=5¬e=419https://www.youtube.com/channel/UCndcNrLt5Y5SDobFQbjtCaQ?view_as=subscriber
Merci pour les conseils.
J’ai réécris la routine pour avoir un meilleur aspect, c’est plus gourmand mais plus beau, de toutes façons j’ai un peu de marge :). J’ai aussi fusionné les routines FireUpdate et FireDraw en une seule routine afin de calculer le feu directement depuis le buffer de l’écran, en 1×1. Il n’y a plus beaucoup de place pour des optimisations :
DrawFire: movem.l d0-d4/a0,-(sp) ; Store registers move.l _FirePower,d4 ; Get power move.l _CgxBaseAddress,a0 ; Get screen move.w #SCRH-1,d0 ; y < height-1 .loopY ; For y move.w #SCRW-2,d1 ; x < width-2 clr.w d2 ; Reset Pixel .loopX ; For x ; CLK Pipe clr.w d3 ; Reset Color ; 1 0 move.b SCRW*1-0(a0),d2 ; Pixel = Pixel(x+0,y+1) ; 1 1 add.l d2,d3 ; Color + Pixel ; 2 0 move.b SCRW*3-0(a0),d2 ; Pixel = Pixel(x+0,y+3) ; 2 1 add.l d2,d3 ; Color + Pixel ; 3 0 move.b SCRW*2-1(a0),d2 ; Pixel = Pixel(x-1,y+2) ; 3 1 add.l d2,d3 ; Color + Pixel ; 4 0 move.b SCRW*2+1(a0),d2 ; Pixel = Pixel(x+1,y+2) ; 4 1 add.l d2,d3 ; Color + Pixel ; 5 0 add.l d4,d3 ; Color + Power ; 6 0 lsr.w #2,d3 ; Color >> 2 ; 7 0 beq.s .next ; If Color > 0 { ; 8 0 subq.b #1,d3 ; Color-- ; 8 1 .next ; } move.b d3,(a0)+ ; Pixel(x,y) = Color ; 9 0 dbf d1,.loopX ; Next x ; 9 1 /10 addq.l #1,a0 ; Screen++ dbf d0,.loopY ; Next y movem.l (sp)+,d0-d4/a0 ; Restore registers rts ; Return
La routine ci-dessus tourne à environ 100 frames par seconde en full screen 320x240x8bits sur ma Vampire, grandement aidé par les accès mémoire très rapides de cette dernière et par l’exécution superscalar (2 pipes).
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.@Flype :
Est-ce que des outils de développement (des assembleurs, lesquels) ont été adaptés aux nouvelles instructions du Core Apollo ? Par exemple aux instructions sur 64 bits ?
Je crois que quand les versions pour A500 et A1200 seront disponibles, je vais me laisser tenter. 🙂
Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
@Jul
Pour le moment non :\ Un candidat serait probablement ASM-One car il est relativement à jour, j’ai une version 1.49-RC2 de 2008, donc c’est pas si vieux que çà. Pour Devpac, c’est mort, source fermé. Ensuite GnuASM est aussi un très bon candidat et sans aucun doute le plus ‘facile’ a adapter pour Gunnar.Ceci dit, il est possible, je l’ai testé, d’écrire des macros en assembleur pour exécuter les nouvelles instructions, et de fait, çà marche avec n’importe quel compilateur. Une instruction étant une suite de bits, c’est pas très compliqué. Il faut être bien documenté surtout. Une include de macros bien foutues sera la bienvenue dans un premier temps.
A part çà, une ch’tite vidéo ? 🙂 allez go…
(MystiCube, écran RTG 640x480x16bits ==> 40/50fps, écran RTG 640x480x8bits ==> 100/110fps)
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Driver P96 retiré pour l’instant. Certains points de licencing et choix stratégiques doivent être étudiés sereinement avant de le diffuser largement.
@ntsc Il me semble que ce sont des demos RTG, pas besoin d’aga.
L’aga sera pour le GOLD core.
Edit : toutes mes confuses, POUET indique que ce sont bien des demos aga !
Edit 2 : Par contre A.D.A les listes dans aga/gfx.
http://ada.untergrund.net/?p=demo&i=132
http://ada.untergrund.net/?p=demo&i=251
Edit 3 (le retour dela revanche du fils) : Sinon il y a Machinist d’Elude qui est 060 et RTG proof
Pouet se trompe, ou du moins ne précise pas assez. Ce sont bien des démos 100% os-friendly, RTG. AGA certes, s’il est présent. Beaucoup de démos propose un mode RTG. Beaucoup moins sont RTG et sans FPU. Mais il y a de quoi s’amuser quand même.
Podcast tout frais d’une interview de Gunnar :
http://www.amigapodcast.com/2016/02/amicast-episode-10-biggun-apollo-team.html
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Il est bien trop tôt pour tirer des conclusions. La carte n’est pas encore assez diffusée pour çà ; et c’est sûr que les demomakers apprécieront avoir un FPU.
Je suis curieux de savoir ce que pense @Jul de cette interview ; s’il pense toujours que c’est de la banale émulation. Perso, j’ai trouvé l’interview plutôt intéressante, et il parle même de mon fire effect à un moment.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.@Flype :
J’avais commencé à écouter, mais comme je suis en pleines corrections de copies de partiels, je ne peux pas passer deux heures sur ce podcast : ça va devoir attendre le week-end prochain.
Mais attention, en écrivant “banale émulation” tu mets une nuance péjorative que je n’ai jamais mise. 🙂
Je me borne à dire que le fait que le FPGA doive être programmé (que toutes ses portes logiques doivent être “configurées” sur des positions précises, si tu préfères) cela fait du Core Apollo un émulateur, techniquement, le FPGA étant quant à lui la machine hébergeant l’émulateur.
PC -> WinUAE -> Amiga émulé
FPGA -> Apollo -> Amiga émulé (ou plutôt 68k + autres périphériques)Cela rend, pour moi, l’expérience un peu moins originale qu’avec un vrai 68k gravé. Mais cela est compensé par la vitesse apportée, les modes graphiques, et le fait que cela utilise le vrai matériel de l’Amiga tout autour. On doit vite oublier que c’est un FPGA qui anime tout ça. Comme je l’ai dit plus haut, j’en acquerrai volontiers un pour mon A500 et un autre pour mon A1200. 🙂
Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
Je me demande si la FPU est vraiment nécessaire. En embarqué les fpu ne sont pas souvent présente et on utilise les opérations “fixed point”. En 32bits la précision est suffisante pour pas mal de trucs, et en 64bits le fixed-point devient super efficace.
Je me borne à dire que le fait que le FPGA doive être programmé (que toutes ses portes logiques doivent être « configurées » sur des positions précises, si tu préfères) cela fait du Core Apollo un émulateur, techniquement, le FPGA étant quant à lui la machine hébergeant l’émulateur.
Techniquement un “émulateur”: Non pas du tout! Tout se programme dans l’électronique de nos jours. On utilise plus des cpu à brancher sur une carte mère. Par exemple, sais tu que ARM ne fournit aucun chip à plugger sur une carte mère de telephone, de raspberry ou autre. Non il fournit un code source qui programme les portes logiques pour avoir les fonctions armv7 ou armv8. Tout marche comme ca en electronique et personne ne parle d’émulation armv7 ou v8. Il n’y a que toi qui persiste à appeler émulation ce qui est de l’électronique moderne.
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 › Matériel › Vampire et Phoenix Core