maximiser la fenêtre, puis F11 puis F5
A lire de préférence avec Mozilla/Firefox
 
 
HSF 2009
Le projet GPL :
Gaming Platform Libre :-)
 
La console du troisième type

 

Yann Guidon - Laura Bécognée
samedi 27 juin 2009
version définitive


 
Yann Guidon : 32 ans, électronicien, LED designer, amateur d'architectures de processeurs (F-CPU depuis 1999)
 
Laura Bécognée :
21 ans, idéo-phile passionnée de systèmes électromécaniques,
arme secrète
 
GPL
"Concept console" portable qu'on voudrait prototyper mais qu'on ne fabriquera pas en série (ce n'est pas notre vocation).

Au menu :

Comment on en est arrivés là ?

  • Un geek et son processeur libre (YASEP)
  • Une geekette et son extrudeuse
  • Un atelier d'électronique
  • Beaucoup de frustrations de joueurs
  • Une envie de travailler ensemble sur un projet technologique, fascinant et fun !!1!!

    • Une console de jeu portable permet de toucher à tout : son/musique, graphisme, IA, rendu, communication, interfaces et périphériques, organisation et outils de développement... On va donc communiquer avec plein de gens aux profils très différents !

     

    L'isolement des jeux libres

    Quels jeux trouve-t-on ?
  • Jeux sous GPL (Wormux, TuxRacer, Alien Arena, FreeCiv/LinCity...)
  • Plus ou moins "domaine public" (Doom et autres "classiques")
  • "Sasfépus"/abandonware exclus (non Libres)
  • "Homebrew" sur consoles : assez confidentiels, "loaders" consoles
  • Pas d'ouverture dans les circuits de distribution "officiels" (game stores, boutiques en lignes Xbox/PSx/Nintendo)
     
    Confusion entre Libre et gratuit :
    les jeux libres ne sont pas reconnus
    • Les plateformes des jeux libres

  • Plateformes existantes (consoles portables/salon, PC/MAC)
  • Les bornes d'arcade sont exclues ;-)
  • Quelques consoles "Linux" obscures (type ARM: GP32, GP2X, OpenPandora)
  • Dépendance de Linux/BSD
  • OpenGL, DirectFB, SDL
  • Imperméabilité entre les plateformes (Linux/MS/consoles...)

    Constat :
    Les jeux libres sont essentiellement des suiveurs
    • Les premières générations :
    (PC, MAC, Atari, Amiga, GameBoy...)
     
    Non "protégés" => copie "sauvage"
    => DRM intrusif, abusif et inefficace...
     
    analogie : squat
     
    ==> jeu du chat et de la souris, "Corewars", machines virtuelles...
     
    ==> Soucis pour les éditeurs et les utilisateurs
    mais profusion de solutions compatibles,
    et baisse des prix des plateformes
    Plateformes "verrouillées" :
    PlayStation Portable, XBox...
     
    DRM intégré dans le kernel
    analogie : boite de nuit avec physio et videur
     
    ==> Développement de solutions de "cracks" (marché parallèle de "modchips")
    ==> Ennuis et coûts pour les utilisateurs,
    ==> Coûts pour les développeurs,
    faux sentiment de sécurité
    ==> Introduction d'un intermédiaire obligé :
            le fabricant de la console
     
    Prix artificiellement élevé
    Le marché des jeux vidéo dépasse celui de la musique (USA : 16 milliards US$ en 2008)
     
    Le développement d'un jeu vidéo de dernière génération coûte des dizaines de millions de dollars et doit être développé, promu, amorti, hébergé, publié, présenté, distribué...
    It's business as usual

    Les Logiciels Libres ne jouent pas le même jeu, leur réputation de manque de flexibilité commerciale leur ferme le marché.
     
    Quid de Linux sur PS2 ?
    "Si le Libre ne peut pas tourner sur une plateforme propriétaire, les jeux propriétaires peuvent-ils venir sur une plateforme Libre ?"
     
    Oui si on crée une plateforme adaptée mais
    La plateforme du 3ème type
    Analogie : je suis le propriétaire et je gère ma maison, que je loue si je veux.

    On cherche un juste milieu entre "libre" et "propriétaire", on voudrait les avantages (faire ce qu'on veut) sans les inconvénients (blocage de la plateforme) tout en apportant des garanties de confidentialité...

    Le système doit être sécurisé mais flexible pour accepter les deux types de contraintes. Une gestion fine des droits d'accès (d'écriture et de lecture) aux différentes parties de la plateforme est nécessaire.

    Début de solution

    Actel fournit une solution presque adaptée avec la famille de FPGA ProASIC3.
    FlashLock
    2 clés programmées par JTAG :
  • clé des droits d'accès
  • clé d'encryption du bitstream (AES 128 bits)
    • Le bitstream crypté ne contient aucune clé (authentification)
     
    Droits :
  • Lecture/écriture/vérification du FPGA
  • Lecture/écriture de la FlashROM

    • Différents niveaux et types de protection sont possibles. Le FPGA peut être complétement verrouillé ou ouvert. Ou entre les deux.

    Inconvénients

    Flash => Retard de process sur la concurrence Pas assez de SRAM interne

    Améliorations pour ProASIC4 ?

    Application dans GPL : le contrat de confiance entre éditeur, joueur et fabricant
    Les usages "commercial" et "custom" sont donc possibles sur une même machine (mais pas simultanément).
  • Un bitstream de jeu crypté sera lié à la machine et ne servira que sur celle-ci.
     
  • Souci avec Actel : Fichier de "déblocage" nécessaire
      - comme un dé-SIMlockage
      - à fournir au client sur demande
      - Invalide les jeux déjà achetés car la clé AES est effacée, sauf si retour en usine pour reblocage
    • Attention à l'ingénierie inverse et les analyses différentielles (de jeu à jeu ou d'une version cryptée à une autre)
     
    ==> "générateur de CPU" avec fonctions obfusquées (swap/xor de broches etc.)

     

    YASEP
     

    Yet Another Small Embedded Processor

  • Original (pas un clone donc pas de brevet)
  • Libre (Affero GPL)
  • Rupture avec certains aspects de F-CPU
  • Coeur de processeur codéveloppé en :
    • JavaScript pour la documentation et les outils de programmation
    • VHDL pour ASIC & FPGA
  • Configurable en 32 ou 16 bits avec jeu d'instructions (quasi) identique
    • Environnement de développement Web2.1 :
     
  • Entièrement en ligne sur http://yasep.org
  • Compatible tout navigateur sauf MSIE
  • Tous les paramètres définis en JavaScript
  • Manuel interactif
  • Assembleur/désassembleur intégré
  • Persistence sur disque local
    •  
    Prévus :
  • Programmation non-textuelle avec simulateur intégré (débug continu)
  • Import de langage C ?
  • Flashage du programme web-based
    (CGI ou interface SPI sur Ethernet)
    • Modèle de programmation :
     
  • Type RISC compact, orienté microcontrôleur
  • Instructions simples et orthogonales sur 16 bits, avec champ 16 bits optionnel
  • Environ 40 opcodes de base, déclinables avec conditions ou champs immédiats
  • 16 registres accessibles
         dont 5 "normaux" et 1 NextPC
  • Pas de saut (JMP/branch) :
         écriture (conditionnelle) dans NPC
  • Pas de load/store : Register-mapped memory (5 paires de registres pour accéder à la mémoire, avec auto-update de pointeur)

    • Instructions courtes : 2 formes

    (La destination est écrite en dernier.)

    ADD R2,R1
    R1 <= R1 + R2
    1514131211 109876 543210
    src/Imm4 src/dest opcode Reg court
    R2 R1 ADD 0 0
     
    ADD [-8..7],R1
    R1 <= R1 + imm4
    1514131211 109876 543210
    src/Imm4 src/dest opcode Imm4 court
    2 R1 ADD 1 0
    Instructions longues : 2 formes principales
    ADD R2,[-32768..32767],R1
    R1 <= R2 + Imm16
    31302928 27262524 23222120 19181716 1514131211 109876 543210
    Imm16 src/Imm4 src/dest opcode Imm16 long
    12345 R2 R1 ADD 0 1

    ADD R1,R2,R3
    R3 <= R1 + R2
    31302928 27262524 23222120 19181716 1514131211 109876 543210
    dest2 Reg src/Imm4 src/dest opcode Ext long
    R3 0 R2 R1 ADD 1 1
    ADD R1,[-8..7],R3
    R3 <= R1 + Imm4
    31302928 27262524 23222120 19181716 1514131211 109876 543210
    dest2 Reg src/Imm4 src/dest opcode Ext long
    R3 1 5 R1 ADD 1 1
    Instructions longues : options étendues

    Auto-update de pointeurs ou opérandes :

    ADD R1+,R2,R3
    R3 <= R1 + R2, R1 <= R1 + 1
    31302928 27262524 23222120 19181716 1514131211 109876 543210
    dest2 update Reg src/Imm4 src/dest opcode Ext long
    R3 +   0 R2 R1 ADD 1 1

    2 champs identiques pour mettre à jour src/dest et dest2 :
    00 pas de mise à jour
    01 post-incrémente
    10 prédécrémente
    11 post-incrémente
    Ce mécanisme facilite l'accès à la pile, aux données consécutives etc.
    Instructions longues : options étendues

    Exécution conditionnelle :

    ADD R1,R2,R3 LSB0 R4
    Si R4 est pair alors R3 <= R1 + R2
    31302928 27262524 23222120 19181716 1514131211 109876 543210
    src cond dest2 cond Reg src/Imm4 src/dest opcode Ext long
    R4 R3 LSB0 0 R2 R1 ADD 1 1

    Conditions :
    Always (défaut) Never (réservé)
    Z (Zéro) NZ (not zéro)
    LSB0 (pair) LSB1 (impair)
    MSB0 (positif) MSB1 (negatif)

     

    GPL

     

    L'objectif est de mettre au point dans le futur une console de jeu vidéo d'une puissance équivalente à une Nintendo DS, si possible mieux.

    GPL doit être évolutif et permettre une mise au point progressive. Les tâches sont réparties en 2 parties :

    Module d'application
  • Module puissant, interchangeable, avec une interface bien définie.
  • Doté d'un FPGA et de SDRAM.
  • Fréquence interne : 100 à 200MHz.
  • Eventuellement : port CompactFlash.
  • Situé sous l'écran.
  • Chargé de tous les calculs et de l'affichage en couleur.
    • Système de base :
  • SoftCore de puissance moyenne
  • FPGA non volatile et SRAM
  • Chargé de l'interfaçage avec tous les périphériques
  • Doit gérer tous les protocoles
  • (re-)Configure le module d'application
  • Détecte l'écran et génère les timings
  • Communique par messages full-duplex
  • Doit pouvoir afficher en cas d'erreur

    •  

    GPLv0

     

    GPLv0 est une étape intermédiaire avant d'obtenir GPL. Tout est concentré dans un SoftCore compact mais suffisant pour des jeux de type Nintendo GameBoy.
    Une fois prêt, il suffira de concevoir la communication avec le module d'application et le multiplexage des signaux vidéo pour obtenir GPL.

  • SRAM : 512K octets (256K×16 bits) 15ns
    GS74116A / CY7C1041 / IDT71V416...
  • 15ns de temps d'accès => cycle mémoire 50MHz
  • Boot : Flash série (SPI) de 512KO à 4MO
  • FPGA : Actel A3P600(L)
  • CPU : YASEP16 (Mul, Pages, 8 threads HW, pas de cache)
  • Ecran : LCD 320x200 mono tactile
    (4 niveaux de gris => 19200 octets < 64K)
  • Batterie : 1 LiPo plat 1Ah sous l'écran
    + 1 ou 2 bâtons LiIon 3Ah dans les poignées
  • Sortie Péritel ou VGA (autodétection)
    • Plusieurs bus SPI
  • Rapide / longs paquets, 5 à 50Mbps :
    • Flash boot série
    • Ethernet : ENC28J60
    • Wireless : 24L01
    • slot MMC/SD
  • Lent / court <= 10Mbps :
    • Accéléromètre 3D (LIS3LV02)
    • Digitaliseur touch screen (MXB7846/ADS7846)
    • La coque pourrait être prototypée par une extrudeuse "maison"
     
    Par exemple RepRap ou des projets similaires (Modello)
     
    RepRap n'est pas encore assez mûr pour le projet, sa complexité d'assemblage et de fourniture ainsi que son coût sont les deux obstacles majeurs.
    Happy hacking,
    LB+YG