Vampire et Phoenix Core

15 sujets de 466 à 480 (sur un total de 1,122)

  • Alexandre JALON

    • Messages : 318
    #243490

    La première Vampire pour 1200 alors ?

    Ou l’AGA (voir SAGA) implémenté dans la V2 du 600 ?

    Polom

    • Messages : 77
    #243492

    Je vais vérifier pour le screen, peut être posté trop vite 🙂

    Pas d’AGA sur le Vampire mais des modes RTG ! Et pas de Vampire 1200 pour le moment.

    flype

    • Messages : 1097
    #243543

    Oui, surement une erreur.

    Le dernier bench, sur la vampire v2 de majsta, c’est celui là :
    v2

    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: 72Mflops

    Les 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.

    seg

    • Messages : 1153
    #244731

    Elle existe depuis longtemps cette page?

    http://www.apollo-core.com/bringup/index2.htm

    lolof

    • Messages : 749
    #244740

    Oups, double post 🙁

    lolof

    • Messages : 749
    #244741

    Ouaaa, cela donne un meilleur score Sysinfo que mon GBA1000/[email protected]

    flype

    • Messages : 1097
    #244757

    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.

    Anonyme

    • Messages : 956
    #244774

    une raison a la fermeture du forum? (j’avoue ne pas suivre de super près la vampire)

    seg

    • Messages : 1153
    #244775

    @flype

    C’est pas censé être reconnu comme un 060?

    Sinon, comment es-tu renseigné des avancées au jour le jour?

    Anonyme

    • Messages : 2976
    #244777

    Ptete ici

    https://kiwiirc.com/client

    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>

    flype

    • Messages : 1097
    #244814

    @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.


    @seg

    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-team

    A600 Rev 1.5 + Vampire 600 V2-128.
    A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.

    flype

    • Messages : 1097
    #244817

    Quelques info de Kipper2K ici :
    http://eab.abime.net/showthread.php?p=1042446#post1042446

    On 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.

    flype

    • Messages : 1097
    #244824

    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.

    seg

    • Messages : 1153
    #244829

    Ils te disent quoi tester précisément ou c’est en mode « hasard »?

    Sinon, good job et merci pour la communauté. Va falloir que je me bouge le cul moi aussi…

    flype

    • Messages : 1097
    #244839

    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.

15 sujets de 466 à 480 (sur un total de 1,122)

  • Vous devez être connecté pour répondre à ce sujet.

Forums AmigaOS, MorphOS et AROS Matériel Vampire et Phoenix Core

Amiga Impact