Apollo Team : Le point du mois d’aout

Forum News Room Actualités Apollo Team : Le point du mois d’aout

  • Ce sujet contient 7 réponses, 6 participants et a été mis à jour pour la dernière fois par Jim Neray, le il y a 4 années et 6 mois.
  • Créateur
    Sujet
  • #97322
    Gortek
      • Level 2
      • Messages : 43

       

      La team Apollo a fait un petit point sur leur travaux. Voici le status update en français:

       

      Vampire V4 Standalone

      Un nombre gigantesque d’heures a été passé sur le sous-système graphique au cours des derniers mois et le noyau a été presque entièrement retravaillé.

      En partant de la révision 7383 du noyau, nous pouvons souligner les améliorations de la nouvelle version 7649 :

      – De nombreuses améliorations AGA augmentant le nombre de jeux AGA fonctionnant parfaitement
      – Support complet de la souris Amiga sur le port DB9
      – Prise en charge de l’image dans l’image pour des applications telles que RiVA, ce qui signifie qu’un plein écran peut désormais être affiché dans une fenêtre. En d’autres termes, vous pouvez désormais lire une vidéo dans une fenêtre de Workbench 1.3.

      – Nouvelles fonctionnalités améliorées pour les canaux audio
      o Prise en charge d’un échantillon long de 16 bits audio 64 Mo
      o Audio plus de bits de volume
      o Positionnement libre de l’audio (« audio free positioning ») / Panning L/R
      o Mode « one-shoot » audio

      – Nouvelle fonction Sprite améliorée
      o Sprite en mode 16 couleur
      o 256 Sprite avec leur propre registre de couleurs réservé
      o Mode Sprite Indirect, rendant la maintenance du Sprite beaucoup plus facile à coder

      – Copper 32 bits
      – La fonction vidéo ModeID – qui permet un codage plus facile des écrans Chunky
      – Chunky est maintenant pleinement synchronisé avec le VBL
      – Chunky est désormais programmable par le copper

      Le plus grand changement notable est maintenant que le noyau affichera une résolution fixe et y fusionnera la sortie native Amiga et le RTG. Les résolutions inférieures à celle affichée sont mises à l’échelle dans cette résolution fixe, ce qui signifie que vous n’aurez plus ces changements de résolution constants comme avec le noyau précédent et que vous bénéficierez d’une ouverture d’écran instantanée.

      Certains choix ont dû être faits pour trouver le meilleur compromis entre l’affichage du Workbench dans une résolution utilisable tout en maintenant une bonne qualité de mise à l’échelle pour les jeux. Au stade actuel, le nouveau noyau ouvrira une résolution de 960×540 sur votre écran et affichera parfaitement n’importe quel jeu WHDLoad. L’inconvénient est que Workbench ne peut pas afficher plus de 960×540 pour le moment. Nous pourrions envisager de fournir un noyau avec une résolution de 720p mais avec une mise à l’échelle « pas si bonne » des jeux WHDLoad pour répondre aux souhaits de chacun.

      En raison de ce grand changement, une mise à jour du pilote est nécessaire et le SAGA Driver Package est mis à jour en conséquence à partir de la version 2.3.
      https://wiki.apollo-accelerators.com/doku.php/saga:updates

       

      AROS et ApolloOS

      La décision a été prise en équipe de bifurquer du code source AROS existant afin d’accélérer le développement de sa branche m68k. Le raisonnement de ce choix est que AROS embarque actuellement beaucoup de code pour différentes plateformes (x86, ARM, 68k) ce qui n’est pas pertinent dans notre cas. Le fait de pouvoir supprimer tout ce code inutilisé facilitera le développement (temps de compilation plus court, compréhension plus aisée du code), apportera rapidement des améliorations sur la table et améliorera éventuellement les performances du groupe.

      Notre objectif est d’améliorer le support de l’AROS 68k et d’augmenter sa compatibilité avec l’AmigaOS3 au meilleur niveau possible. Pour atteindre cet objectif, quelques courageux volontaires de l’équipe ont commencé à maintenir cette branche et le code est entièrement disponible sur GitHub.
      https://github.com/ApolloTeam-dev/AROS
      https://github.com/ApolloTeam-dev/AROS/wiki/Building

      Pour montrer et démontrer les améliorations apportées, l’équipe a également commencé à travailler sur une distribution complète basée sur ce système, appelée ApolloOS, qui peut être téléchargée et testée dans sa dernière version.

       

      GOLD2.13

      Grâce aux efforts et au dévouement de l’équipe, la branche GOLD2 pour les accélérateurs V2 continue d’évoluer dans le but d’améliorer cette branche autant que possible. Nous savons tous que le FPGA pour les V500 et V600 est très complet, mais cela ne nous interdit pas d’apporter des correctifs.

      GOLD2.13 apportera des améliorations sur ces sujets :
      – Sur la V1200, les deux IDE de la carte mère, PCMCIA, et Vampire FastIDE fonctionneront en même temps
      – Sur la V1200, la vitesse de la ChipRAM a été augmentée à 7,0 Mo/s, ce qui en fait la bande passante la plus rapide disponible avec un accélérateur A1200
      – Backport du mode tortue unifié V4 avec bit PCR, ce qui signifie que le mode tortue peut maintenant survivre aux redémarrages si nécessaire (pour les jeux ou les démonstrations sur disquettes)
      – La FPU fixe l’instruction FSQRT

      Il n’y a pas encore de date de disponibilité prévue. Il reste encore du travail à faire pour l’amener dans un état où nous serons heureux et confiants lors de sa diffusion.

       

      Nous passons de Slack à Discord

      Slack a été très utile pour le canal de support V4 au début mais nous voyons beaucoup de limitations qui peuvent à peine être levées même avec la version payante. C’est pourquoi nous avons testé Discord pendant quelques semaines pour nous assurer que si nous demandions aux personnes sur Slack de déménager, cela leur offrirait une meilleure expérience.

      Discord présente de nombreux avantages par rapport à Slack :
      – Pas de perte d’historique, vous pouvez rembobiner les journaux ad vitam aeternam
      – Fonction de vidéoconférence intégrée
      – L’application mobile est plus rapide que celle de Slack
      – Il a été utilisé par de nombreuses personnes dans le cadre de la rétrospective, le passage d’un serveur à l’autre se fait en un seul clic

      Pour faciliter cette transition, un pont a été mis en place entre Slack et Discord afin que vous ne manquiez rien si vous êtes un peu en retard pour rejoindre Discord.

      Dans les prochains jours, un courriel sera envoyé à tous les clients de Vampire pour les informer de l’existence de ce nouveau serveur Discord.
      https://discord.gg/TsKm6ym

       

      Production

      Si vous n’avez pas vécu sur la face cachée de la lune pendant les 6 derniers mois, vous avez peut-être remarqué que notre monde a dû subir des événements inattendus à cause de COVID-19. Cela a eu un impact direct et instantané sur la production des cartes Vampire et continuera probablement à montrer ses effets jusqu’à ce que les choses s’améliorent sur la planète et surtout en Chine.

      Comme presque tous les fabricants de matériel, nous nous approvisionnons en Asie et subissons d’énormes retards de livraison, alors que les choses peuvent même être livrées, puisque certaines expéditions se sont même perdues. Quelqu’un qui s’engage aujourd’hui sur une ETA ou qui dit que les problèmes de livraison sont résolus est évidemment dans l’erreur et ne doit pas être cru.

      Il y a une forte demande de cartes Vampire que nous avions déjà du mal à satisfaire, mais cette situation de pandémie vient de mettre encore plus de pression sur nos épaules.

      Nous en sommes vraiment désolés et comme cela est hors de notre contrôle, nous comptons sur votre compréhension et votre patience. Cela prendra du temps, mais nous n’oublions aucun d’entre vous.

      Le côté positif de cet enfermement sanitaire est que, comme nous n’avons pas pu nous concentrer sur la production, nous avons eu la possibilité d’améliorer certains de ses procédés pour l’avenir. Par exemple, le Vampire V4 Standalone a bénéficié de quelques améliorations de la disposition qui supprime certaines étapes de soudure manuelle. Ainsi, lorsque nous serons à nouveau en mesure de produire, cela devrait aller plus vite qu’auparavant.

       

      Logiciel

      Du côté des logiciels, nous avons de nouvelles applications liées aux vampires qui se matérialisent actuellement :
      – Milkytracker bénéficie d’un support audio natif complet pour Vampire grâce aux efforts répétés de Neoman et Marlon
      – Alynna Trypnotk travaille actuellement sur une version bootable du pilote microSD.
      https://github.com/alynna/sagasd-device
      – Jan a rendu sa distro AmiKit compatible avec Vampire V2 et V4
      https://www.amikit.amiga.sk/vampire

       

      Source:
      http://apollo-core.com/
      https://apollo-accelerators.com/
      https://github.com/ApolloTeam-dev/AROS

    Affichage de 7 réponses de 1 à 7 (sur un total de 7)

    Partager sur vos réseaux sociaux préférés :
    Facebooktwitterredditpinterestlinkedintumblrmail

    • Auteur
      Réponses
    • #97355
      Staff
      Jim Neray
        • Level 22
        • Messages : 7168

        Merci Gortek pour ta publication. Je l’ai passé en actualité du coup ;-)

        A500 - A500 Plus - A600 HD - A1200 - A2000 - A4000T - CD32 - C=64 - 1040STE - CPC6128
        Mon Amiga 500 Plus : A590, 2MB Chip, 2MB Fast, HD 1,2GB, Floppy ext.
        Mon Amiga 1200 : Blizzard 1220/4, 2MB Chip, 4MB Fast, HD 80GB, Overdrive CD

        - Micromiga.com - La boutique Amiga -


        #97363
        mmu_man
          • Level 0 - Newbie
          • Messages : 8

          Le fait de pouvoir supprimer tout ce code inutilisé

          Euh… si du code x86 gène le dev 68k c’est qu’il est mal rangé. S’il rallonge la compilation c’est qu’il est compilé pour rien. Dans les deux cas ça se corrige, plutôt que de le supprimer pour le restaurer ensuite pour merger… :wacko:

          #97365
          francouai
            • Level 8
            • Messages : 711

            core 2.13 totalement inutile pour la Vampire V500+ on dirait.

            ils ne parlent meme plus du core3. :cry:

            --
            Francois.

            #97366
            Gortek
              • Level 2
              • Messages : 43

              Le fait de pouvoir supprimer tout ce code inutilisé

              Euh… si du code x86 gène le dev 68k c’est qu’il est mal rangé. S’il rallonge la compilation c’est qu’il est compilé pour rien. Dans les deux cas ça se corrige, plutôt que de le supprimer pour le restaurer ensuite pour merger… :wacko:

              Il y a bien une séparation des architectures avec un dossier arch pour chaque machine. Mais dans le code principal, il y a aussi aussi beaucoup de cas à gérer et je pense qu’ils veulent se simplifier la vie et ne pas avoir à tester sur x86 à chaque fois pour voir si rien n’est cassé … il ne faut pas oublié que l’inverse s’est produit. Pendant un bon moment Aros m68k ne fonctionnait plus. Il leur faudrait plus de manpower … tant que c’est opensource, on ne peut pas trop se plaindre.

              #97395
              Kaeril
                • Level 5
                • Messages : 156

                Je ne suis pas sûr de bien comprendre l’intention derrière ce fork. Est-ce que la distribution résultante sera réservée au hardware Vampire, ou bien on parle d’un AROS m68k « générique » ? La logique commerciale voudrait que ce soit plutôt la première option, mais je voudrais de tout coeur que ce soit la seconde.

                L’état d’AROS 68k de façon générale est effectivement très déprimant, et dès mon arrivée dans le monde Amiga en début d’année c’est quelque chose qui m’a beaucoup surpris. Il existe un remplaçant open-source et maintenu par la communauté d’AmigaOS et du Workbench, mais personne ne semble penser que la priorité serait de pouvoir le faire effectivement tourner sur un Amiga 500 avec un niveau de performance similaire à AmigaOS 3.1. Notez que je ne me plains pas, je comprends très bien la problématique du manque de bras et de personnes compétentes pour s’emparer du sujet. Difficile d’exiger quoi que ce soit quand c’est des passionnés qui font ça gratuitement sur leur temps libre. C’est juste que les choix de priorité du projet AROS, même s’ils s’expliquent historiquement, me semblent aujourd’hui ne pas vraiment répondre aux attentes de la scène Amiga actuelle. Et j’aimerais beaucoup que l’initiative de la team Apollo puisse faire avancer les choses pour tout le monde, et pas juste en les réservant à leur hardware.

                Je ne sais pas si mon post est très clair en me relisant… :lol:

                #97396
                Staff
                Aladin
                  • Level 25
                  • Messages : 15163

                  Ben Aros 68k existe déjà (si l’on peut dire). Là c’est pour un Aros 68k optimisé 68080/SAGA. Tout le monde peut travailler sur AROS. Après avoir dit cela, tout travail sur cet Aros 68k optimisé bénéficiera forcément pour tout amiga 68k en changeant les drivers SAGA par des plus conventionnels.

                  #97399
                  Staff
                  Jim Neray
                    • Level 22
                    • Messages : 7168

                    Il est vrai qu’AROS est toujours resté un peu à la marge. Espérons donc que cette version optimisée pour Vampire tire de manière plus globale AROS 68k vers le haut.

                    A500 - A500 Plus - A600 HD - A1200 - A2000 - A4000T - CD32 - C=64 - 1040STE - CPC6128
                    Mon Amiga 500 Plus : A590, 2MB Chip, 2MB Fast, HD 1,2GB, Floppy ext.
                    Mon Amiga 1200 : Blizzard 1220/4, 2MB Chip, 4MB Fast, HD 80GB, Overdrive CD

                    - Micromiga.com - La boutique Amiga -
                  Partager sur vos réseaux sociaux préférés :
                  Facebooktwitterredditpinterestlinkedintumblrmail
                  Affichage de 7 réponses de 1 à 7 (sur un total de 7)
                  • Vous devez être connecté pour répondre à ce sujet.