Vampire et Phoenix Core
-
La première Vampire pour 1200 alors ?
Ou l’AGA (voir SAGA) implémenté dans la V2 du 600 ?
Oui, surement une erreur.
Le dernier bench, sur la vampire v2 de majsta, c’est celui là :
Les perfs du FPU sont bien au dessus d’un FPU ‘classic’, c’est là dessus que bosse gunnar ces dernières semaines.
CPU: 63Mips – 68040 – 2.5 instructions/cycle en moyenne (IPC).
FPU: 72MflopsLes accès cpu/fast sont annoncés très rapides : ~230mb/sec.
Particularité depuis l’ajout du fpu :
Les registres du fpu et cpu sont accessibles dans les deux sens afin d’avoir beaucoup plus de registres utilisables.La team a aussi trouvé cette semaine le bug de voltage sur la carte. Ils ont perdus quelques semaines là-dessus. Ca va peut-être avancer plus vite maintenant.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Elle existe depuis longtemps cette page?
En effet, cette page date de 2 ou 3 jours max.
Gunnar a splitté la page en 2.
index1.htm pour la Vampire 1.
index2.htm pour la Vampire 2.A ce sujet, il s’agit ici des scores de la Vampire V2, prototype 2.
Ce prototype est celui qui avait 64Mo de RAM.Majsta a presque fini les dernières touches de la Vampire V2, prototype 3 qui, en principe, sera la dernière avant production run. Celle-ci dispose de 128Mo, physiquement un peu plus grande aussi, et accès mémoire encore plus rapide (entre autres).
Petite histoire du jour :
Un bug important a été trouvé aujourd’hui grâce à un test unitaire en ASM. Il est bien caché dans le DCache, et il pourrait bien expliqué les instabilités connues mais jusque là non identifiées.NB: L’équipe est toujours très active malgré la fermeture du forum. Et Kipper2k a commencé à s’entraîner à souder cette v2 et il s’est procuré du bon matos pour çà.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.une raison a la fermeture du forum? (j’avoue ne pas suivre de super près la vampire)
Ptete ici
Select a user name and join the channel #apollo-team
<p style= »margin-top: 4.0pt; margin-bottom: 6.0pt; »>and also keep an eye on this forum for updated news releases.</p> @zeGouky
La raison de la fermeture du forum est un crash de la base SQL suite mauvaise manip, historique perdu. Gunnar a tenté de la restaurer sans succès et vu son intérêt, il ne s’est pas pris plus la tête dessus. A priori, il va quand même rouvrir bientôt car il permet de travailler, occasionnellement, en décalé (contraintes fuseaux horaires des membres de l’équipe) et de permettre aux intéressés de s’exprimer.
Au départ, oui. 68000, puis 68060, puis 68020. Maintenant 68040, ce qui est – quand on connaît les CPU Motorola – une avancée importante. Un 68040 est plus complexe, au sens plus d’instructions que le 68060. En revanche, le 68060 est mieux pensé que le 68040 (sans détailler trop, le pipeline, caches et compagnie sont nettement plus efficaces). L’implémentation de Gunnar du 68040 permet d’être compatible avec toutes les instructions de la famille Motorola 680×0 (hors MMU pour l’heure), tout en étant proche du 68060 dans sa conception interne. Bref, depuis peu, le core Apollo est Full 680×0, il intègre toutes les instructions de tous les CPU de la famille. Ce qui est juste énorme.
Je suis renseigné car je me connecte à l’IRC de l’Apollo-Team quelques fois, voire régulièrement, et surtout je suis en contact direct avec la team puisque je participe au débogage du core, en réalisant des tests unitaires en ASM (Devpac pour ma part).
[EDIT]
J’ai vu un jour une signature d’un gars, je ne sais plus qui, qui disais ‘Et vous, vous faites quoi pour l’Amiga ?‘. Cà m’a interpellé. J’ai décidé çà il y a quelques mois. Sans plus de moyens que çà, la préservation de l’Amiga tel que je l’aime, c’est à dire avec un Motorola 68K inside n’a pas d’autre issue que le FPGA (mais attention, State of the Art). Il y a aussi Cosmos indirectement qui m’a interpellé dans cette aventure. Je me suis donc mis à l’ASM, partant de zéro. J’ai aidé Gunnar de temps en temps avec mon niveau de merde. Et puis à force, la team m’a ouvert les portes 😉 J’ai trouvé 5 bugs importants. Je rappelle (voir quelques pages / mois en arrière) que la team recherche du monde volontaire pour faire des tests du core M68K 😉 Je sais qu’il y a des gars ici qui ont largement le niveau pour tester (fiabiliser) le CPU, dans l’intérêt de la communauté. C’est un jeu marrant : pièger le CPU. Le M68K est vraiment un beau processeur, il ne doit pas mourir. Par contre loin de moi l’idée de penser un quart de secondes qu’il revienne sur le devant de la scène. Mais, au moins qu’il permette à l’Amiga Classic de rester dans la partie.@craf
Oui, c’est çà, perso j’utilise comme çà, je change mon pseudo et zou :
https://kiwiirc.com/client/irc.kiwiirc.com/?nick=MonPseudo|?&theme=cli#apollo-teamA600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns. Quelques info de Kipper2K ici :
http://eab.abime.net/showthread.php?p=1042446#post1042446On y voit des solutions techniques proposées par Kip pour la fameuse sortie HDMI, et plus anecdotique, un port clavier PS/2.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns. Allez, pour le fun, je partage un petit exemple de ‘testcase’ en ASM (ici pure 68000) :
;================================================= ; Base64 Encode (v1.3) - flype ;================================================= ; +----------------+---------+---------+---------+ ; | Text content | M | a | n | Input: 3 chars ; +----------------+---------+---------+---------+ ; | ASCII | 77 | 97 | 110 | ; +----------------+---------+---------+---------+ ; | Bit pattern |010011|01|0110|0001|01|101110| Step1: Bits operations ; +----------------+------+-------+-------+------+ ; | Index | 19 | 22 | 5 | 46 | Step2: Base64 Encode Table ; +----------------+------+-------+-------+------+ ; | Base64-encoded | T | W | F | u | Output: 4 chars ; +----------------+------+-------+-------+------+ ;================================================= ; Constants ;================================================= assert_zero EQU $00D0000C ; Magical Apollo register ;================================================= ; Entry Point ;================================================= Start: lea String1,a1 ; encode 1st string lea Buffer1,a2 ; jsr Base64Encode ; lea String2,a1 ; encode 2nd string lea Buffer2,a2 ; jsr Base64Encode ; lea Buffer1,a0 ; check 1st string lea Precal1,a1 ; jsr SelfTest ; lea Buffer2,a0 ; check 2nd string lea Precal2,a1 ; jsr SelfTest ; rts ; stop #-1 ; stop execution ;================================================= ; SelfTest SubRoutine ; A0 = Calculated string ; A1 = Precalculated string ;================================================= SelfTest: move.b (a0)+,d0 ; read calculated char beq SelfTestExit ; exit if null-char sub.b (a1)+,d0 ; compare with precalculated char move.l d0,assert_zero ; raise error if D0 != 0 bra SelfTest ; continue SelfTestExit: rts ;================================================= ; Base64 Encode SubRoutine ; A1 = String to encode in Base64 ; A2 = Buffer for encoded string ;================================================= Base64Encode: lea B64EncodeTbl,a0 ; base64 encode table clr.l d0 ; init registers clr.l d1 ; clr.l d2 ; clr.l d3 ; store 4 bytes, and flush it to buffer .Base64EncodeLoop: move.b (a1)+,d0 ; encode 1st char beq .Base64EncodeExit ; exit if null char move.b d0,d1 ; ( a >> 2 ) lsr.b #2,d1 ; move.b (a0,d1),(a2)+ ; move.b (a1)+,d1 ; encode 2nd char move.b d1,d2 ; ( ( a & %00000011 ) << 4 ) | ( ( b & %11110000 ) >> 4 ) lsl.b #4,d0 ; ( ( a << 4 ) & %00111111 | ( b >> 4 ) andi.b #%00111111,d0 ; lsr.b #4,d2 ; or.b d0,d2 ; move.b (a0,d2),(a2)+ ; move.b (a1)+,d2 ; encode 3rd char move.b d2,d0 ; ( ( b & %00001111 ) << 2 ) | ( ( c & %11000000 ) >> 6 ) lsl.b #2,d1 ; ( ( b << 2 ) & %00111111 ) | ( c >> 6 ) andi.b #%00111111,d1 ; lsr.b #6,d0 ; or.b d1,d0 ; move.b (a0,d0),(a2)+ ; andi.b #%00111111,d2 ; encode 4th char move.b (a0,d2),(a2)+ ; ( c & %00111111 ) bra .Base64EncodeLoop ; continue .Base64EncodeExit: rts ; exit subroutine ;================================================= ; Base64 Encode Table ;================================================= B64EncodeTbl: dc.b 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' dc.b 'abcdefghijklmnopqrstuvwxyz' dc.b '0123456789+/' ;================================================= ; ASCII strings to encode in Base64 ;================================================= String1: dc.b 'Amiga Rulez!',0 Buffer1: dc.b '________________',0 Precal1: dc.b 'QW1pZ2EgUnVsZXoh',0 ;================================================= String2: dc.b 'ASM 68K is fun.',0 Buffer2: dc.b '____________________',0 Precal2: dc.b 'QVNNIDY4SyBpcyBmdW4u',0 ;=================================================Ce test est celui qui a permis de trouver le dernier bug dans le DCache.
Ici, je suis parti d’un cas concret. Une fonction encodage en Base64 (simplifié mais fonctionnel).
Il y a 2 phrases (String1 et String2) à encoder en Base64.
Les résultats encodés sont stockés dans Buffer1 et Buffer2 respectivement.
Sur un vrai 68000, les résultats attendus sont Precal1 et Precal2, respectivement. Ces résultats ont été vérifiés sur mon A1200 ou WinUAE. Mais sur un 68000 implémenté dans un FPGA, » peut-être » que les résultats obtenus ne correspondront pas aux résultats attendus.
La différence est testée grâce au bloc ‘SelfTest’.
L’instruction move.l d0,assert_zero stoppe la simulation si D0 est différent de 0 et met en évidence un bug dans le core.Voilà, çà montre un peu ce que je fais pour la team, à mon niveau.
Avec çà, on sait si le CPU se comporte bien. C’est le quid de la compatibilité, vérifié à bas niveau. Pour avoir fait une quarantaine de tests, je sais que le core est quand pas mal. Après, l’équation comporte quelques inconnues malgré tout. Mon niveau n’est pas non plus terrible, terrible, d’autres tests plus malins pourraient montrer d’autres bugs, et reste aussi le quid de la compatibilité dans l’environnement global d’un Amiga (avec les chipsets, interruptions, timers, …). Ce CPU aura forcément, inéluctablement des problèmes avec les jeux qui se basent sur des timings tricks. Ce CPU vise autre chose, un OS / Workbench confortable et assez puisssant pour supporter quelques portages permettant de préserver la survie du Classic.A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns. Bonne question, cà dépend. C’est comme la police 🙂 Quand on sait pas où chercher, soit on fait rien soit on tapes sur tout le monde. C’est le mode hasard comme tu dis. A ce jeu, n’importe quel test est bienvenu. Même simple, il peut révéler des anomalies, sait-pn jamais. Mais, bien sûr, quand Gunnar donne des indices, cà permet de cibler. Dans le test plus haut, j’ai suivi quelques uns de ces conseils afin de tester plusieurs choses (lecture + écriture dans la fast, plusieurs instructions en 1 cycle grâce aux 2 ou 3 pipes et à la prédiction, et aussi le cache d’instruction et bien sûr toutes les instructions ci-présentes). Mais bon, dans l’ensemble n’importe quel test intégré au développement est une preuve supplémentaire de l’intégrité de l’implémentation du core, et également preuve de non régression lors des updates du core. J’ai évidemment d’autres exemples pour ceux que cà intéresserait.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Vampire et Phoenix Core
