Une des grandes motivations derrière Kamaku est de développer de A à Z (autant que possible) un système complet, du matériel au logiciel, afin d'avoir une vue précise du fonctionnement de chaque élément, à chaque niveau. Je ne prétends pas avoir tout réalisé seul de A à Z, mais j'ai fait en sorte de connaître le fonctionnement intime de chaque "morceau" que j'ai réutilisé (que ce soit un circuit, un logiciel - compilateur par exemple, etc.).

R: Quand ça sera prêt ! Plus sérieusement, pas avant mi-2009 au plus tôt.

Q: Je veux pouvoir faire tourner Kamaku sur ma borne. Combien ça va me coûter ?

R: Le gros morceau est une carte de prototypage architecturée autour d'un FPGA Virtex2Pro de chez Xilinx : la XUP-V2P (fiche technique). Outre la carte elle-même, SG15 comprend une barette de 256 Mo de DDR et une carte Compact Flash de 1 Go. Le tout est relié à la borne JAMMA via un J-Pac de chez Ultimarc.

Q: Un FPGA, c'est quoi ?

Pour une réponse détaillée, je vous renvoie à la définition sur Wikipedia.

Pour une réponse simpliste, un FPGA est un circuit reconfigurable. On peut l'imaginer comme une énorme réserve de portes logiques qui peuvent être connectées comme on le souhaite. Concrètement, on peut décrire un circuit (soit en dessinant les portes logiques dans un logiciel dédié, soit en le décrivant via un langage de haut niveau tel que Verilog ou bien VHDL), puis utiliser un logiciel qui va transformer cette description en "fichier de configuration" pour le FPGA. Un connecteur spécial (JTAG) permet d'envoyer ce fichier de configuration dans le FPGA lui-même, qui se reconfigure alors pour prendre les propriétés électroniques exactes du circuit initialement décrit.

Ce qu'il faut bien réaliser, c'est qu'un FPGA n'est PAS un processeur que l'on peut programmer en C ou en C++ pour simuler le comportement d'un circuit électronique. C'est un circuit que l'on peut RECONFIGURER pour qu'il possède les propriétés physiques exactes du circuit que l'on veut.

R: J'utilise un J-Pac par commodité, pour ne pas avoir à souder des gros câbles disgracieux sur ma carte de prototypage hors de prix. Comme les possesseurs de MameCab le savent, le J-Pac ne fait qu'amplifier le signal vidéo, sans aucune transformation. SG1 sort bien un signal vidéo à 15 kHz en natif.

Outre l'amplification vidéo, le J-Pac fournit une interface PS/2 pour les contrôles, ce qui est plus pratique à utiliser pour le débuggage qu'un panel de borne.

Le J-Pac est donc une solution élégante pour brancher la XUP-V2P sur un peigne JAMMA sans prendre le risque de l'exploser, mais il est envisageable de s'en passer sans trop de problèmes (même si ce n'est pas dans mes plans immédiats).

R: La XUP-V2P ne comporte aucun processeur au sens classique du terme. Néanmoins, le FPGA (Virtex2Pro), élément central de la carte, comporte en son sein 2 cores de PowerPC405 (un processeur RISC 32 bits assez répandu). Ces cores ont 3 avantages :

1. ils sont gravés de manière indélébile dans le FPGA, les utiliser ne prend donc aucune ressource supplémentaire
2. ils ont été soigneusement optimisés et peuvent soutenir des fréquences jusqu'à 350 MHz
3. ils répondent aux normes des PowerPC, et on peut donc utiliser un compilateur "standard" supportant l'architecture PPC405 (par exemple gcc) pour produire du code machine qui leur soit intelligible à partir de langages de haut niveau comme C/C++, sans avoir à écrire le code machine ou le compilateur soi-même
   

Pour Kamaku, l'avantage n°3 est indéniable, puisque cela signifie que je peux utiliser des outils libres déjà particulièrement au point pour produire du code exécutable. Actuellement, j'utilise un de ces 2 coeurs comme élément central de mon design, et je le fais tourner à 100 Mhz comme le reste du circuit.

Attention, je parle bien ici de "core" de PowerPC. En effet, il ne s'agit pas d'un processeur complet et fermé. En particulier, il est possible d'y greffer de nouvelles unités de calcul, de changer les caches, ou ce genre de joyeusetés.

R: Un bus local 64 bits sur lequel sont branchés :

• un PPC405
• un contrôleur DDR
• un contrôleur BRAM (mémoire interne au FPGA) de 64 Ko
• un DMA spécialisé dans les transferts de gros sprites opaques (idma)
• un DMA spécialisé dans les transferts de sprites moyens avec transparence (isprite)
• un contrôleur vidéo 15 kHz + circuit d'affichage des petits sprites (ivga2)
  

Un bus périphérique 32 bits sur lequel sont branchés :

• un pont vers le bus local
• un contrôleur pour le lecteur de Compact Flash
• un contrôleur pour le codec AC97
• un contrôleur d'interruptions
• un contrôleur pour le port série de debug
• un contrôleur pour le port PS/2 (boutons de la borne via le J-Pac)
• un contrôleur pour les boutons de la XUP-V2P
• un contrôleur pour les interrupteurs de la XUP-V2P
• un contrôleur pour les LEDs de la XUP-V2P
  

Plus une dizaine de petits circuits utilitaires servant à gérer les horloges, le reset de la carte, la reconfiguration du FPGA...

R: Ma première tâche, qui n'est pas forcément la plus évidente, c'est de conceptualiser les choses et de trouver des solutions raisonnables à tous les problèmes présents, mais également d'anticiper les problèmes futurs.

Pour le matériel physique, à part le choix de la carte et comment la brancher sur une borne, je n'ai pas eu à dégainer le fer à souder, ce qui est une bonne chose pour la survie des pauvres composants ^_^

Pour le matériel logique, j'ai réalisé 3 circuits (saurez-vous deviner lesquels en regardant la liste de la question précédente ? :p). Les autres sont fournis par Xilinx, le constructeur de la carte. Néanmoins, ce n'est pas tout d'avoir les circuits prêts, il faut également les organiser, les connecter, et surtout comprendre comment fonctionnent ceux qui sont déjà faits, ce qui n'est pas forcément une tâche triviale quand on parle d'un bus, d'un codec audio ou bien d'un coeur de processeur !

Pour le logiciel de "bas niveau", les circuits fournis par Xilinx sont également fournis avec des drivers. Quand plusieurs étaient fournis, j'ai bien entendu utilisé celui de plus bas niveau ^_^ Y rajouter les 3 drivers pour mes 3 circuits customisés (écrits en C).

Vient ensuite la couche que j'appelle "librairie", et qui est à mi-chemin entre un mini système d'exploitation et une collection de librairies. Pour Kamaku, cette couche s'appelle FOLIAGE (encore un acronyme mystère !) et a été écrite en C++ (avec quelques petites touches d'assembleur).

Finalement, la couche logicielle à proprement dite, à savoir... le jeu :) Prévu pour être écrit en C++, et n'utiliser que FOLIAGE pour une séparation propre du logiciel et du matériel !

R: Ils sont au nombre de 3 :

ivga2

• génère le signal vidéo 15 kHz
• affiche le contenu d'un framebuffer en mémoire centrale, sur lequel sont ajoutés dynamiquement jusqu'à 4096 "petits sprites" (16x16) parmi 64 types affichables simultanément, tout en gérant leur transparence et leur débordement hors de l'écran
• gère la synchronisation verticale en interrompant le processeur entre chaque frame
  

isprite

• DMA spécialisé dans la copie de sprites depuis la mémoire vers le framebuffer (lui aussi en mémoire)
• peut lire un sprite de taille 64x64, avec transparence
• peut le copier à volonté n'importe où dans le framebuffer, tout en gérant sa transparence et en minimisant les accès au bus central grâce à un algorithme sophistiqué de calcul dynamique de "caractéristiques" de transparence

idma

• DMA spécialisé dans la copie de sections de gros sprites depuis la mémoire vers le framebuffer
• ne gère pas la transparence ni l'alignement mémoire
• utilisé pour le scrolling du background
  

R: Il est difficile de comparer SG15 aux systèmes existants. Au niveau puissance de calcul, le processeur central est à peu près équivalent à un 486 SX/100 (donc sans coprocesseur arithmétique). Au niveau mémoire, la plupart des circuits embarqués ou consoles de jeu disposent d'une faible quantité de mémoire à accès rapide. SG15, au contraire, embarque une forte quantité de mémoire à accès lent, mais à débit très élevé. Il dispose également de circuits conçus spécialement pour afficher un grand nombre de sprites à l'écran. On ne peut donc pas dire que SG15 est plus ou moins puissant que tel ou tel autre système, il a ses spécificités qui le rendent performant dans son domaine d'application précis, mais ce qui est sûr c'est qu'il ne vaut mieux pas s'en servir comme d'un supercalculateur !

R: Actuellement, non. Dans le futur, très probablement. Il est à peu près certain qu'un SDK (kit de développement logiciel) verra le jour d'ici la fin du développement de Kamaku. Le délai réel dépendra sûrement du nombre de personnes qui se montreront intéressées par un tel SDK. Ces personnes pourront donc développer en C++ en utilisant directement FOLIAGE, sans avoir à se soucier des basses crasses du matériel sous-jacent. Je préviens tout de même dès maintenant qu'une compréhension fine du développement logiciel sera nécessaire, ne serais-ce qu'à cause des fortes contraintes logicielles et de l'absence de débuggueur. Bref, il faudra quand même vous attendre à en chier plus qu'avec une bête SDL, même s'il ne sera pas nécessaire de parler l'assembleur de PPC405 au quotidien pour y arriver.

R: Actuellement, non. Dans le futur... disons... peut-être. Il faut quand même savoir que tripatouiller dans les circuits logiques de SG15 nécessite de nombreuses compétences à tous les niveaux de l'informatique et de l'électronique numérique, ainsi qu'un budjet conséquent (le hardware est cher, mais ce n'est rien par rapport au prix du software nécessaire pour développer dessus). Je ne vais pas m'avancer sur la disponibilité un jour d'un HDK (Hardware Development Kit), je préfère régler la question directement avec d'éventuels candidats à la damnation intellectuelle éternelle.

R: Tout le matériel a été réalisé grâce aux outils Xilinx. Les circuits ont été designés sous ISE Fundation 8.1, le système général assemblé sous EDK 8.1, et débuggé via Chopscope Pro 8. Ils n'ont pas été simulés, mais directement implémentés puis débuggés en situation réelle.

Le logiciel a été édité sous divers IDE (EDK, Eclipse, DevC++, Visual Studio 2005), et compilé grâce à la chaîne d'outils GNU (gcc, objcopy, ld, as...). Aucun débuggeur n'a été utilisé pour débugguer le logiciel directement sur le carte, par manque d'outils "efficaces" et rapides. Tout le débug a donc été fait à la main, ou alors via un désassembleur (ou, pour le cas les plus critiques, en analysant les données transitant sur les bus via Chipscope Pro).

R: 30% VHDL (conception des circuits)
10% C (drivers)
5% assembleur PPC405
55% C++ (librairies)