Coup de ménage
13 Octobre 2004

Cela faisait longtemps que le site Coldfire n'avait pas évolué. C'est dorénavant chose faite. Ceci dit, il ne s'agit que d'un léger saupoudrage: déplacement du site vers un nouvel hébergement et protection de l'adresse E-Mail contre le spam.

Pour ce qui est d'informations plus excitantes, sur des sujets tels que le microprocesseur Coldfire ou l'avenir des compatibles Atari, il faudra attendre encore. Et ce n'est malheureusement pas de ma faute s'il n'y a rien d'intéressant à écrire sur le sujet. Je vous invite donc à vous rendre sur le newsgroup fr.comp.sys.atari pour être tenu au courant de l'évolution des choses au jour le jour.
Accès en format web à fr.comp.sys.atari hébergé chez Google

Bon sang, mais c'est bien sûr!
17 Juillet 2001

Pourquoi faire compliqué quand on peut faire simple? Je parle là des propositions d'alternatives raisonnables proposées dans l'article du 12 juillet. Il existe une solution en effet: plus efficace que le 5307 et disponible, contrairement au 5407e.

LA solution, c'est le 5407 (tout court, sans "e"). Il est disponible. Ses caractéristiques sont un peu moins performantes que le 5407e, mais il est quand même tout à fait acceptable:
- 257 MIPS à 162 MHz
- 16K de cache instructions
- 8K de cache données
- Unité MAC
- Contrôleur mémoire compatible SDRAM
- 2 ports série
- 4 canaux DMA
- 2 timers
- port parallèle (16 bits E/S)
- port I²C

Les inconvénients:
- Pas de MMU
- Pas de FPU

Pour y parvenir, voici ce qu'il suffit de faire:
- Placer le processeur sur une carte fille
- Prévoir le routage du bus USB jusqu'à la carte fille
- Accepter une cadence de bus variable 50-54 Mhz (5307), 75-83 MHz (5407)
- Le support de SDRAM sera placé, soit sur la carte fille, soit sur la carte mêre, selon les impératifs techniques.

Après ce petit cours de "yaka", espérons que Medusa Computer Systems pourra nous sortir un Pegasus le plus vite possible. C'est tout/tous ce que nous espérons.

Pas bonne nouvelle
12 Juillet 2001

La nouvelle est tombée sur le site X-TOS cette semaine. Le processeur ColdFire 5407e attendu pour la carte-mêre du Pegasus voit sa sortie commerciale repoussée au second trimestre 2002. Coup dur pour tout ceux (dont moi) qui espéraient cette nouvelle machine pour remettre à niveau leur matériel Atari. Ceci dit, cela n'est guère étonnant, le 5307, précédente puce de même catégorie produite par Motorola avait déjà connu un retard de 9 mois lors de sa sortie.

Cependant, l'équipe de X-TOS ne se démoralise pas pour autant. Ils disent qu'ils n'attendront pas aussi longtemps pour sortir une nouvelle machine compatible Atari. Ils sont actuellement à la recherche d'une "alternative raisonnable" pour parvenir à leurs fins. Idéalement, une solution technique permettant un recentrage sur le ColdFire 4e mais réalisable avant la mi-2002.

Il n'y a pas plus d'informations sur le site X-TOS. Gageons que, même si j'ai précédemment dit qu'ils ne se démoralisaient pas, leur moral à dû néanmoins en prendre un sacré coup, et le nôtre, clients potentiels, aussi. Maintenant, restent les spéculations sur ce que serait cette "alternative raisonnable", il y en a plusieurs.

- Utilisation d'un 68040 ou d'un 68060. Peu probable: le coût de la puce est élevé, sa disponibilité est aléatoire, ne disposant pas des périphériques intégrés au ColdFire, il faudrait les implanter sur la carte mêre (gestionnaire d'interruptions, DMA, GLUE, Gestionnaire de D-RAM, ports série et parallèle), d'ou un coût supplémentaire et un double usage dès l'arrivée des 5407e.

- Utilisation d'un PowerPC. Peu probable aussi: tout comme un 68K, la puce coûte cher, et même si elle est disponible et est rapide, il faudra également implanter sur la carte-mêre les périphériques manquants.

- Utilisation d'un ColdFire 5307. Fort possible: toutes les entrées-sorties sont déjà présentes. Inconvénients: le contrôleur mémoire aura certainement une génération d'écart avec le 5407e, le port USB est absent, la cadence d'horloge ne dépasse pas 90 MHz, ce qui ne permettrait pas, en mode compatible 68K, d'espérer plus que la vitesse d'un Milan 040 ou hadès 040. Par contre, si le processeur est placé sur une carte fille, avec la connectique prévue pour l'USB, un simple remplacement de celle-ci, pour un budget de l'ordre 500 FRF, tout au plus, permettrait de passer au 5407e.

- Utilisation de puces folkoriques: Nuon, Transmeta ou autre. Improbable: certaines de ces puces permettent théoriquement l'émulation de processeurs divers simplement en leur fournissant un nouveau jeu d'instructions. Dans la pratique, seule l'émulation x86 est prévue, elle n'est pas très rapide (surtout adaptée aux portables) et cela ne résoud pas le problème des périphériques manquants.

Malencontrueuse erreur
12 Février 2001

Une erreur est venue se glisser dans l'article "Du 68K au ColdFire". J'avais utilisé un move.b à la fin du code de conversion du add.b pour replacer les codes-condition tels qu'ils devaient être. Or, n'ayant relu la doc de l'instruction move quand j'ai écrit l'article, je pensais que celle-ci laissait les codes C (carry, retenue) et V (overflow, débordement) inchangés. C'est une erreur: le move remet systématiquement à zézo C et V (mais pour quoi faire, franchement?). Conséquence: désormais, j'émulation du add.b se voit doté d'une sauvegarde du CCR (condition codes register, registre des codes-conditions) dans la S-RAM, le temps d'effectuer le transfert du résultat final par un move.

La conversion du code 68K en code ColdFire
07 Février 2001

Bon, il était grand temps d'aborder la question. Un nouvel article traîtant du sujet en profondeur vient d'être installé dans la rubrique "Du 68K au ColdFire". Cet article est encore incomplet, de nombreuses parties seront ajoutées par la suite, plus d'instructions y seront traîtées. J'espère bien que ceci entraînera des discussions sur le sujet. Pourquoi ne pas installer un forum sur ce site, après tout?

Des précisions sur le X-TOS
02 Février 2001

Le projet X-TOS dispose maintenant de son nom définitif: Pegasus. Décidément, Fredi reste très orienté vers la mythologie grecque.

Quelques détails sur la config de base:
-Première présentation publique: avril 2001
-CPU ColdFire 5307e (avec FPU et MMU) à 225 MHz.
-TOS 3.06 (comme sur Hadès) en flash EPROM
-Carte mêre équipée PCI2, AGP2 et USB2
-Drivers pour carte graphique ATI Rage Pro
-Drivers pour diverses cartes son
-Prix estimé entre 5500 et 7000 FF (sans disque dur)

Curiosités de l'émulation 68K
29 Janvier 2001

Le jeu d'instructions du ColdFire étant un sous-ensemble du jeu d'instructions 68K, un Atari équipé de ce dernier sera capable de faire tourner des applications compilées pour le Coldfire (tant que le code ne contient pas une des instructions ajoutées pour faciliter le portage des applications!).

On se retrouve cependant face à un curieux paradoxe. Si une application 68K tournant sur CF (ColdFire) est plus lente qu'une application native, c'est également vrai dans le sens inverse. Une application compilée CF sera plus lente sur 68K qu'une application compilée pour ce dernier. En effet, les modes d'adressage .b et .w du 68K ne sont pas utilisés, tout étant traîté en .l, d'ou plus d'instructions pour une même opération et des instructions plus lentes à l'exécution.

A propos de la compatibilité Coldfire - 68K
25 Janvier 2001

S'il y a bien un point sur lequel Motorola a toujours communiqué de façon très floue au sujet de ses ColdFire, c'est bien la compatibilité 68000. Il y a quelques années, la parenté avec le 68K n'était même pas mentionnée dans les data book de la marque.

La sortie du 5407 a marqué une évolution, toute une série d'instructions destinées "à faciliter le portage des applications issues des générations précédentes de microprocesseurs" ont été ajoutées. Il s'agit d'instructions permettant la conversion de données byte et word vers des données long. Mais là est bien le plus gros problème du ColdFire: en interne seul le mode d'adressage long existe.

La plupart des applications Atari existantes, qu'elles aient été écrites en assembleur, en C ou en d'autres languages utilisent intensivement les modes .b et .w (les calculs sur les longs sont plus lents sur un 68000), cela va poser de gros problèmes de compatibilité des applications. Pourtant quelle curieuse idée de ne travailler que sur des longs (comme c'est également le cas dans les PowerPC), une chaîne de caractères, par exemple, n'est pas constituée de longs.

Pour résoudre ce problème, il faut émuler les instructions manquantes. Il y a trois façons d'y parvenir.

1/ Une émulation temps-réel où les codes inconnus sont convertis au fur et à mesure par le biais du trap ILLEGAL. En fait, l'émulation des instructions manquantes par ce biais n'est pas la solution idéale, il y beaucoup trop de perte de temps entre l'exécution de l'exception et du RTE, le décodage de l'opcode et du mode d'adressage et la sauvegarde des registres nécessaires pour le code de l'émulateur.

2/ La recompilation du code lors de l'installation du programme en mémoire. Le problème, c'est que ça ne marche pas avec les programmes qui ont du code automodifié ou qui se testent au démarrage (c'est le cas de Calamus). C'est une solution très performante, on peut retrouver une vitesse assez élevée et il est probable qu'une solution sera trouvée pour permettre le lancement de Calamus (qui est une des applications Atari les plus avides de puissance de calcul)

3/ La solution royale: la compilation d'applications natives ColdFire à l'aide d'un compilateur C adéquat, le GCC au hasard (ou CodeWarrior pour ceux qui ont un Mac et les bibliothèques GEM qui vont bien). Toutes les applications Atari écrites en C et dont les sources sont libres ou dont l'auteur continue à maintenir son programme pourront bénéfier de ce lifting miracle.

Le plus surprenant, c'est que les 3 méthodes peuvent cohabiter simultanément! L'émulateur d'instruction ILLEGAL peut être présent. Si le programme a été recompilé au lancement, il ne verra rien passer et tout ira bien. Et si une application compilée en natif est lancée, le recompilateur "run-time" laissera le code inchangé puisqu'aucune instruction spécifique 68K ne sera présente.

Merci à Olivier Landemarre de m'avoir rappelé les problèmes de la lenteur de l'émulation. Et l'absence des modes d'adressage que j'avais passés sous silence dans l'article d'ACC magazine (paru initialement il y a plus d'un an).

Des nouvelles du projet X-TOS
23 Janvier 2001

Plus d'infos sur le projet mené par Frédi Aschwanden, le concepteur du Médusa et de l'Hadès. En définitive, le microprocesseur choisi sera le 5407e de Motorola. Il s'agit d'une version améliorée du 5407 intégrant un FPU (coprocesseur arithmétique) et une MMU (très pratique pour les applications multitâche).

En revanche, contrairement à ce qui est dit sur le site X-TOS, le 5407e n'est pas 100% compatible au niveau du code avec le 68000. Les instructions manquantes subsistent toujours, ainsi que de nombreux adressages .b et .w qui font cruellement défaut pour les applications Atari (voir l'info suivante).

Le 5407e est annoncé en version 225 MHz pour le premier trimestre 2001 et en version 333 MHz pour la fin de l'année. Le X-TOS est quand à lui annoncé pour juin prochain, ce qui constitue une échéance raisonnable quand on connait le talent de Frédi. Il dispose très certainement à l'heure actuelle d'une carte de test basée sur un 5407 standard connectée à une carte-mêre d'Hadès et qui fonctionne avec divers programmes de test.

Pour frédi le travail restant se divise en deux branches. D'une part l'écriture du code nécessaire à l'émulation des instructions manquantes. Et d'autre part la mise au point d'une nouvelle carte-mêre, certainement basée sur celle de l'Hadès, mais optimisée pour en réduire le prix (tous espèrent un X-TOS en entrée de gamme entre 6000 et 7000 FRF) et intégrant des interfaces au goût du jour (USB, FireWire, AGP(?)...).

Ce dont on peut être sûr, c'est que Frédi a toujours été très précis dans ses dates de sortie (normal pour un Suisse), on peut donc raisonnablement espérer la machine pour cet été. Et d'autre part, les Allemands ayant toujours favorisé le Milan face à l'Hadès, le marché Français sera traîté d'égal à égal avec le marché d'outre-Rhin en terme de quantités disponibles