Environnement de developpement Dreamcast

Mise en place et étude du développement Dreamcast

C'est lors d'une install party à Metz que j'ai rencontré une personne qui lançait un rendu de Tux sur un écran géant à partir de sa Dreamcast. C'est de là que m'est venue l'idée de développer pour cette console que j'adore.

1. Introduction à la Dreamcast

Qui ne connaît pas des titres comme SoulCalibur, Skies of Arcadia, Grandia 2, Sonic adventure, ou encore le magnifique Shenmue .. Vous me suivez, je vais vous parler de la Dreamcast. Dernière console en titre de Sega(tm), cette merveilleuse console à la mort prématurée fait encore parler d'elle au sein d'une communauté très active sur Internet. En effet, de nombreuses personnes ont décidé de programmer des jeux, des utilitaires, des émulateurs sur cette console. Je pourrais citer le très célèbre ScummVM disponible également sur PC et qui permet de lancer la plupart des jeux de Lucas Art(tm) (Monkey Island, Day of the tantacle, Sam & Max ...), ou encore des émulateurs (cpc, megadrive, néo-géo en cours de développement).
Parmi les jeux Homebrew, pour ma part, deux se détachent du lot : Feet of fury et Alice Dreams. On peut dire que la communauté est vraiment productive et motivée. J'en arrive au but de cet article : mettre en place un environnement de compilation/développement pour Dreamcast au sein d'un système GNU/Linux. Des packs windows existent pour l'environnement de développement dev-cpp, mais je n'aborderai pas ce type d'installation.
Avant toute explication concernant l'installation de l'environnement, passons en revue quelques informations techniques de la console.

2. Historique et Hardware

Figure 1 : La Dreamcast, sa manette et la carte mémoire

Sortie en novembre 1998 au Japon, la Dreamcast est disponible en Europe et aux Etats-unis à partir de Noël 1999. Sega(tm) frappe fort avec sa nouvelle console 128 bits (contre 32 pour la playstation).

A ce sujet, il existe un très bon article paru en 2004, disponible sur le site de jeux videos : jeuxvideos.com.

3. Introduction

Le développement amateur pour les différentes consoles s'appelle : le Homebrew. Il est bien évidemment possible de programmer sur Dreamcast à condition de disposer des bons outils :

• un kit de développement ;
• un moyen de transférer les données du PC vers la console afin de tester les programmes que nous aurons écrits.

Les différentes manipulations seront détaillées ci-après. Fort heureusement, il existe de nombreux logiciels disponibles sur Dreamcast. Le mécanisme de création d'un logiciel est le suivant :

• compiler son projet avec la bibliothèque KOS (Kallisti OS) écrite par Dan Potter. Des snapshots Subversion sont disponibles ici (cf la procédure d'installation est détaillée dans le chapitre suivant) ;
• 3 choix s'offrent à nous pour tester notre programme :
• envoyer le programme via le port série de la Dreamcast. Pour ce faire, il faudra se fabriquer ou s'acheter un coder cable ;
• rendre le binaire "bootable" au format Dreamcast, le graver et mettre le CD dans le lecteur de la console ;
• rendre le binaire "bootable" et le tester sur un émulateur. Malheureusement, il existe peu d'émulateurs. Un seul est disponible : Chankast qui apparemment fonctionnerait plutôt bien, l'inconvénient majeur étant qu'il n'est disponible que sous Windows. J'ai bien essayé de le lancer via Wine, mais sans réel succès.

Avant de passer à la partie technique de l'article, quelques informations pécunières pour ceux qui souhaitent se lancer dans le développement Dreamcast :

• une console d'occasion (manette incluse) se trouve pour une cinquantaine d'euros chez n'importe quel revendeur ;
• le coder cable se trouve sur différents sites spécialisés pour vingt, vingt-cinq euros environ.

Au final, on peut se construire une plateforme de développement on ne peut plus intéressante pour soixante dix euros environ. Passons maintenant aux choses sérieuses : l'installation de l'environnement compilation/développement sur notre GNU/Linux préféré.

4. Kallisti Operating system (KOS)

KOS est l'acronyme de Kallisti Operating System qui sera désigné ainsi dans la suite de l'article. Ce système d'exploitation est considéré comme étant la référence pour le développement Dreamcast. C'est un pseudo système temps réel pour les consoles de jeux vidéos :

• GBA (Game Boy Advance)
• Ps2
• Dreamcast

Son état d'avancement étant le plus important, principalement grâce au grand nombre de gens investis sur cette console, le port Dreamcast est le plus utilisé. Il peut être assimilé à un noyau, comme Linux ou BSD, que nous allons utiliser via une bibliothèque (libkallisti.a) qui sera liée à nos propres programmes. Il est aussi possible d'écrire de nouveaux modules qui seront liés dynamiquement à notre programme. Nous pouvons alors envisager d'ajouter de nouveaux systèmes de fichiers, des pilotes de périphériques, etc. Les possibilités sont infinies. KOS étant un pseudo système temps réel, il est évident qu'il possède des systèmes de fichiers particuliers. En effet, on peut :

• lire sur le cd-rom (accès par /cd) ;
• écrire sur l'ordinateur relié par le coder cable (accès par /pc ; pratique pour faire des impressions d'écran) ;
• lire sur le romdisk (accès par /rd). Ce système de fichiers est directement lié au binaire du programme lors de la compilation (sa taille est limitée à 16 Mo).

KOS dispose aussi de pilotes de périphériques pour le clavier, la souris, les manettes et la carte réseau (10/100Mbits). Assez de théorie, passons à la pratique avec l'installation et l'utilisation sur quelques exemples de cette fameuse bibliothèque. Tout d'abord, récupérons les sources de KOS :

• kos-ports : port de différentes bibliothèques (jpeg, png, ogg, mp3, ...)
• kos-snapshot : sources de Kos

Il faut tout d'abord mettre en place un système de compilation croisée (cross-compiler ou toolchain en anglais) afin d'offrir la possibilité de compiler sur PC et d'exécuter sur Dreamcast. Deux compilateurs croisés seront nécessaires :

• le premier afin de générer du code pour le processeur SH-4 ;
• le second afin de générer du code pour le processeur ARM chargé de s'occuper du son.

Attention : un problème connu des versions de gcc supérieures à 3.0.4 nous obligent à utiliser une version 3.0.4 ou inférieure pour le cross-compilateur à destination du processeur ARM. En ce qui concerne le compilateur croisé à destination du processeur SH-4, j'ai utilisé une version 3.4.3 avec des patchs  concernant la gestion des threads (ces derniers seront fournis dans une archive .tar.gz). Une mise en place incorrecte de ces deux compilateurs croisés vous assurera de magnifiques kernel panic, pour peu que vos programmes utilisent les bibliothèques sonores. Liste des archives à récupérer :

• gcc-core-3.4.3.tar.bz2
• gcc-g++-3.4.3.tar.bz2
• gcc-core-3.0.4.tar.gz (pour ARM)
• newlib-1.12.0.tar.gz
• binutils-2.15.tar.bz2
• binutils-2.11.2.tar.gz (pour ARM)
• kos-ports-snapshot-20050618.tar.bz2 kos-snapshot-20050618.tar.bz2

Je vous mets à disposition un script servant à construire les compilateurs croisés à partir de ces archives : dc-chain-0.1.tgz (les patchs y sont inclus)

Copier alors ce script dans le répertoire de votre convenance, par  exemple /tmp/testKOS.

tar xzf dc-chain-0.1.tgz ;
cd dc-chain-0.1 ;
copier "gcc-core-3.4.3.tar.bz2" "gcc-g++-3.4.3.tar.bz2" "newlib-1.12.0.tar.gz" "binutils-2.15.tar.bz2" "kos-ports-snapshot-20050618.tar.bz2" "kos-snapshot-20050618.tar.bz2" dans ce répertoire ;
 for in `ls -1 *.bz2`; do tar xjf $i; done;
tar xzf newlib-1.12.0.tar.gz

4.1 Modification du Makefile

Modifier le makefile, notamment les chemins d'installation des compilateurs croisés : variables sh_prefix et arm_prefix, par exemple :

• sh_prefix := /tmp/testKOS/dc-chain-0.1/dc/$(sh_target)
• arm_prefix := /tmp/testKOS/dc-chain-0.1/dc/$(arm_target)

Renseigner les bonnes versions des logiciels à compiler pour les variables : binutils_ver, gcc_ver, newlib_ver.
Enfin, mettre à jour la variable : kos_root (cette variable représente le chemin où se trouvent les répertoires de KallistiOS. En l'occurence, si vous avez suivi la manipulation ci-dessus, la valeur de cette variable est : /tmp/testKOS/dc-chain-0.1.

Attention : j'ai noté des problèmes de compilation lorque j'essayais de construire le toolchain en utilisant gcc-4.0 ou supérieur. C'est pour cela que je force l'utlisation de gcc-3.4 et g++-3.4 en assignant les variables CC et CXX dans le shell courant de la manière suivante :

• export CC=/usr/bin/gcc-3.4 ;
• export CXX=/usr/bin/g++-3.4 ;

Je vous laisse le soin d'adapter ces manipulations en fonction de la configuration de votre système. Une fois ces différents réglages effectués, entrer les commandes suivantes :

• mkdir dc (répertoire qui va accueillir les binaires des compilateurs) ;
• make patch ;
• make build-sh4 (vous pouvez aller vous chercher un petit café)

Pour construire le toolchain ARM, il suffit de changer dans le makefile, les versions de gcc de 3.4.3 vers 3.0.4 et de binutils de 2.15 à 2.11.2 et de lancer :

• make arm-build (environ 5 minutes sur un Athlon 3000+)

Les deux toolchains sont maintenant construits, nous allons passer à la compilation proprement dite de KOS (ouf !) :

  cd kos
  cp doc/environ.sh.sample ./environ.sh
  éditer environ.sh avec votre éditeur de texte préféré
     - placer dans la variable KOS_BASE le chemin où est décompressé le snapshot de KOS, par exemple : export KOS_BASE="/tmp/testKOS/dc-chain-0.1/kos/"
    - placer dans la variable KOS_CC_BASE le répertoire d'installation du compilateur sh-4, par exemple : export KOS_CC_BASE="/tmp/testKOS/dc-chain-0.1/dc/sh-elf"
    - KOS_CC_PREFIX= sh-elf
    - DC_ARM_BASE = export DC_ARM_BASE="/tmp/testKOS/dc-chain-0.1/dc/arm-elf"
    - DC_ARM_PREFIX = arm-elf

./environ.sh (inclus toutes ces variables dans le shell courant).
  

Les variables que nous avons renseignées sont utilisées par KOS non seulement pour la compilation de la bibliothèque, mais aussi à chaque compilation de projets utilisant KOS. Il faudra donc réaliser cette manipulation à chaque compilation,  ou alors inclure ces variables dans son shell.

4.2 Compiler KOS

Il suffit de taper : make et vérifier que tout se passe bien ;)

4.3 Compiler les bibliothèques

Pour être standard, l'idéal est de placer l'arborescence de ports de bibliothèques au même niveau que le répertoire d'installation de KOS. Dans mon exemple, j'ai compilé KOS dans /tmp/testKOS/dc-chain-0.1/kos/, j'ai donc placé les bibliothèques dans /tmp/testKOS/dc-chain-0.1/kos-port.

tar xjf kos-ports-snapshot-20050409.tar.bz2
cd kos-ports
ln -s ../kos/addons/Makefile
make

Après avoir construit un environnement de développement à destination de la console, nous allons mettre en place les outils de communication PC/Dreamcast.

4.4 Transfert de fichiers vers la Dreamcast

Le moyen le plus facile pour transférer des données entre le PC et la Dreamcast est de se procurer ou fabriquer ce que l'on appelle un coder cable. Des informations sur sa fabrication sont disponibles sur cette page.

N'ayant aucune connaissance en électronique, je me le suis acheté. C'est un simple câble série, nous aurons donc besoin d'outils logiciels de transfert entre le pc et la console, à savoir : dcload/dc-tool. Le site sur lequel se trouvent ces programmes est un site majeur de l'activité autour de notre console bien aimée. On y trouve toutes formes de sources, binaires, documentation ayant un proche rapport avec la console. La première phase est de graver un cd-rom et de démarrer dessus avec sa Dreamcast. Ce CD-ROM met la console en écoute sur le port série. Cette dernière s'occupe une fois le transfert terminé, d'exécuter le programme. La Dreamcast joue alors le rôle de serveur et le pc le rôle de client. Téléchargeons alors les programmes respectifs :

4.4.1 Côté serveur :

  wget http://www.boob.co.uk/files/dcload-1.0.3-1st_read.zip
  unzip dcload-1.0.3-1st_read.zip
  wget http://www.boob.co.uk/files/dcload-1.0.3.tar.gz
  unzip dcload-1.0.3.tar.gz
  cd dcload-1.0.3/make-cd
  ajuster le makefile

Attention, le fichier Makefile est assez ancien. Pour créer les pistes du cd-rom, une commande basée sur cdrecord est utilisée. Il va falloir mettre à jour ce Makefile, car sur les noyaux de la génération 2.6, l'émulation SCSI n'est plus utilisée. Personnellement, j'ai modifié ainsi : CDRECORD = cdrecord dev=ATAPI:0,0,0 speed=8 et j'ai ajusté le chemin du fichier 1st_read.bin. N'hésitez pas à lire la section de l'article concernant la gravure de binaires afin de comprendre ce que nous sommes en train de faire ;).

• make (les fichiers .bin sont dans la première archive précédemment téléchargée).

Pour ceux qui n'ont pas envie de faire cette manipulation, je mets à disposition l'image ISO de ce cd-rom de boot.

4.4.2 Côté client :

  wget http://www.boob.co.uk/files/dc-tool-serial-1.0.3-linux.gz;
  gunzip dc-tool-serial-1.0.3-linux.gz
  chmod +x dc-tool-serial-1.0.3-linux

Pour utiliser le programme côté client : ./dc-tool-linux -x monFichier.elf Vous pouvez maintenant  transférer des données du pc vers la Dreamcast.

Attention :  il faut que l'utilisateur exécutant le programme dc-tool-serial-1.0.3-linux ait des droits d'écriture sur le périphérique /dev/ttyS0 (périphérique utilisé par défaut). Pour voir les paramètres utilisés par dc-tool-serial-1.0.3-linux, il suffit de le lancer sans aucun argument, ce qui fait apparaître ceci :

john@Odyssee$ dc-tool-serial-1.0.3-linux

dc-tool 1.0.3 by 

-x  Upload and execute 
-u  Upload 
-d  Download to 
-a 
  Set address to 
 (default: 0x8c010000)
-s      Set size to 
-t    Use  to communicate with dc (default: /dev/ttyS0)
-b  Use  (default: 57600)
-e            Try alternate 115200 (must also use -b 115200)
-n            Do not attach console and fileserver
-p            Use dumb terminal rather than console/fileserver
-q            Do not clear screen before download
-c      Chroot to  (must be super-user)
-i   Enable cdfs redirection using iso image 
-h            Usage information (you're looking at it)

La partie installation de l'environnement est enfin achevée. La première fois, j'en ai eu pour quelques heures, mais quel bonheur lorsque j'ai lancé mon premier programme sur la console! Nous allons en créer quelques uns dans la partie suivante. Nous arrivons enfin aux choses passionnantes :).