Bitbox, la mini console ARM DIY

Posté par . Édité par Nÿco, Benoît Sibaud, ZeroHeure et palm123. Modéré par Benoît Sibaud. Licence CC by-sa
Tags :
27
28
jan.
2014
Do It Yourself

La console open hardware et open source Bitbox propose une petite console ARM à une seule puce au design ouvert. Le matériel est limité mais suffisamment puissant pour faire de belles choses : microcontrôleur STM32f4 à 168 MHz, 1 Mo de flash et 192 ko de RAM.

La sortie en VGA 640x480 avec 4096 couleurs est réalisée en pur logiciel (pas de GPU, on génère les pixels à la volée vers la sortie VGA). Une version 2 du design en cours de prototypage propose quelques nouveautés comme le son stéréo et les périphériques USB.

Deux trois jeux sont déjà dispos, ainsi qu'un récent emulateur Gameboy !

  • # Playstation Portable

    Posté par . Évalué à 4.

    La PSP est vieille, certes, mais dégomme la Bitbox avec ses deux procos MIPS à 333MHz (oui deux, l'un d'entre eux n'ayant pas accès à la mémoire principale), 64mo de RAM et son GPU.
    La PSP est fermée, certes, au niveau du hardware c'est certain, mais un joli projet du nom de uOFW (unofficial Official FirmWare) attend des contributeurs pour avoir un kernel libre basé sur le reverse du firmware 6.60. On a aussi un SDK non officiel avec un toolchain basé sur GCC.

    Une PSP avec du software entièrement libre serait une merveille pour apprendre à programmer.

    • [^] # Re: Playstation Portable

      Posté par . Évalué à 5. Dernière modification le 29/01/14 à 01:07.

      Tout dépend de la façon dont on veut "apprendre à programmer" : pour du "bare metal", je vois mal un débutant gérer 2 procos comme ça, de but en blanc… Pour apprendre à programmer dans ce cas, plus le matériel est simple, mieux c'est, les Arduino en sont la parfaite illustration !

      En l'occurrence, le fait qu'on trouve des cartes d'évaluation avec un STM32F4 pour une vingtaine d'euros, ça rend ce projet diablement sexy pour qui veut/peut bidouiller un peu du hardware ! En tous cas, ce projet m'interpelle, et je vais suivre ça de près !

      • [^] # Re: Playstation Portable

        Posté par (page perso) . Évalué à 2.

        Oui, mais ce que je comprend pas bien, c'est qu'on peut certainement trouver un proc un peu plus puissant pour une différence de prix modique. Le Freescale IMX233 http://fr.farnell.com/freescale-semiconductor/mcimx233cag4c/mpu-32-bits-i-mx233-ind-128lqfp/dp/2218425 à 400 Mhz par exemple.
        Bon, la mémoire n'est pas intégré, mais ça doit bien exister ?

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Playstation Portable

        Posté par . Évalué à 9.

        Le deuxième CPU est appelé le Media Engine parce qu'il n'est pas directement accessible par le programmeur en userspace. Il est le plus souvent utilisé pour décoder de l'audio MP3/AAC/WMA via des API dédiées.

        Ce que je trouve fascinant dans cette console, c'est le fait que l'architecture soit assez complexe mais qu'au final, le développeur lambda peut tout à fait se limiter à utiliser le CPU principal et le GPU via des librairies qui mâchent le travail. Mais il y a toujours la possibilité de descendre à un niveau plus bas :
        - quelques instructions supplémentaires spécifiques à l'Allegrex (nom de code du CPU), très rarement utilisées
        - le VFPU, unité de calcul SIMD avec 8 banques de 4x4 registres float pour du calcul matriciel. On peut l'utiliser en passant par des instructions ASM. On peut par exemple multiplier deux matrices 4x4 en une instruction, ce qui est plusieurs centaines de fois plus rapide qu'avec le CPU.
        - le Media Engine dont j'ai parlé plus haut qui possède également un DSP que personne ne sait comment utiliser (pour le moment :D)
        - le KIRK engine qui peut générer des nombres aléatoires, calculer des hash SHA1 et encrypter/décrypter en AES
        - le GPU est puissant mais son architecture est extrêmement simple. Suffisamment simple pour pouvoir se passer de la librairie pspgu (équivalent de OpenGL|ES 1.1) et lui balancer directement une liste de commandes, avec un gain de perf conséquent.

        Pour (beaucoup) plus d'infos voir les documentations upspd et yapspd.

        Donc oui, du matériel simple c'est bien. Mais du matériel simple à utiliser ET très performant quand on creuse un peu, c'est mieux !

        • [^] # Re: Playstation Portable

          Posté par . Évalué à 3.

          Le VFPU a l'air trés sympa. Je me suis déjà demandé si un cpu capable d'avoir des opérations sur des matrices pouvaient battre des gpu. Un cpu utilise comme unité de base des nombres sur 8 à 64 bits, voir en vecteur de taille fixe pour le simd, donc une version encore plus fine gérant en plus les matrices devraient offrir des performances sympathiques.

          Sait-on combien il y a d'unité de calcul dans le VFPU ? 4 ?

          Pour ma part j'aurais ajouter des vecteurs 4, en tant que diagonales de matrice 4x4, qui doivent revenir à des quaternions si je me trompe pas. Si on rajoute une gestion de boucle, cela éviterai de faire du déroulage de boucle manuel, qui peut prendre de la place dans le cache de code.

          "La première sécurité est la liberté"

    • [^] # Re: Playstation Portable

      Posté par . Évalué à 1.

      Il y a pas grand chose (a part un arduino) qui dégomme pas la bitbox :) Ah si, ça : https://github.com/makapuf/2313pong
      Bravo aux hackers de consoles, là c'est un peu différent.

  • # Gameduino ?

    Posté par . Évalué à 4.

    Ce serait pas un peu le même concept que la Gameduino ?

    (et je découvre accessoirement que la Gameduino 2 permet de belles choses ! :)

  • # Bienvenue

    Posté par . Évalué à 2.

    Votre projet est très sympa, je salue l'initiative !
    Je vous suivrai de près, même si je n'aurai pas le temps de m'y plonger : en ce moment j'apprends l'asm 65c816 , le proce de la snes et la complexité de la programmation sur cette machine est telle, et mon niveau de départ si bas, que ça me prends la totalité de mon temps libre :)

    • [^] # Re: Bienvenue

      Posté par . Évalué à 2.

      Merci ! et on ne sait jamais, faire un jeu ne demande que de savoir faire du C ! C'est l'avantage d'une architecture plus moderne, c'est quand même sacrément moins baroque :)

  • # 2 puces ?

    Posté par . Évalué à 2.

    Vous n'avez pas pensé mettre 2 puces, et que l'une fasse le boulot d'un GPU ? La génération de l'image VGA doit prendre un temps énorme sur le cpu disponnible.

    "La première sécurité est la liberté"

    • [^] # Re: 2 puces ?

      Posté par . Évalué à 2.

      Justement je trouve ça super élégant qu'il y ait une seule unité de calcul: le but n'est pas de concurrencer les consoles du commerce [ce serait perdu d'avance] mais plutôt d'exploiter au maximum les composants non ?

      J'ai du mal a estimer le cout total du joujou: le STM32f4 est aux alentours de 10€, mais le reste ??

      • [^] # Re: 2 puces ?

        Posté par . Évalué à 5.

        A part la puce, rien ou presque : un régulateur, qq passifs (résistances et condos), 2 LEDs et des connecteurs (VGA, miniDin ou pour la rev1, usb pour la rev2) et microSD et le PCB. Tout ça n'est pas gratuit du tout (surtt si on en fait moins de 10 000 :) et si on ne sponsorise pas comme une carte de dev), mais on peut difficilement faire sans. Donc, en tout, a la louche 30€. Et je dis pas ca parce que j'ai l'idée de faire un kickstarter un jour, pas du tout ;) …

        C'est un des buts du projet : oui on peut ajouter de la RAM externe (aaah 1Mo de RAM le luxe !), oui on peut ajouter un FPGA (gameduino1) ou un EVE800 de FTDI (comme le gameduino2) - ce chip est mortel : j'ai qq fichiers de début de projet avec un eve800+attiny+sortie VGA ) qui génère un signal VGA beaucoup plus simplement que de tout faire à la main, oui on peut acheter un raspberry pi à 30€ faire tourner un émulateur SNES et moins s'emm. :)

        Mais l'idée, si futile soit-elle, était de partir sur un design hardware/software le plus simple et le moins coûteux possible pour pourvoir faire une console DIY du niveau des 16bits.

        L'avantage c'est que rien n'est figé pour la video : si vous voulez mettre 300 lignes en résolution 640 de large puis 180 en 320 de large avec des marges plus grandes pour une video lowres c'est possible :), ou des marges plus grandes ou de l'overscan XYZ …

        En règle générale, c'est vrai qu'il y a des contraintes quand on fait un jeu mais l’expérience montre que c'est bien souvent la RAM qui est plus contrainte que la CPU : on n'a même pas de quoi avoir un framebuffer ! (décompresser de la vidéo plein écran à la volée ? ça vient …)
        En plus l'assembleur ARM c'est pas si compliqué et ça peu resservir …

        Bref, pas mal de contraintes pour sortir quelque chose … mais c'est pour ça que c'est intéressant !

        Reste le petit plus : un port d'extension UEXT qui permettra de brancher tout ce qu'on veut en SPI, I2C ou GPIO comme accessoire .. et d'inventer des jeux ? (qui a dit un collier pour chien électrique ou une sirène 1000W ?)

    • [^] # Re: 2 puces ?

      Posté par . Évalué à 1.

      si bien sur ! de la RAM, un FPGA, un FTDI EVE800, un SoC Mali … Mais ça complexifie (le circuit, le PCB, la dispo des composants ; on restreint la souplesse des interactions kernel/affichage .. donc le coté sioux du soft ) et on commence a rentrer dans la zone ou un raspberry pi est plus intéressant (cf mon commentaire ci après)

      • [^] # Re: 2 puces ?

        Posté par . Évalué à 5.

        Un rasperryPi, c'est aussi un linux, l'idée de rester sans OS, est quand même bien sympathique.

        "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.