— Basé sur les articles publiés dans Quasar CPC numéro 20 et numéro 21, Dossier, par OffseT.

— Il serait intéressant d'ajouter une section expliquant comment programmer ses propres ROMs.

Les ROMs sont longtemps restées confidentielles ; les boitiers d'extension ROM et les ROMs elles-mêmes étaient des équipements chers à l'époque. Toutefois, la Ramcard et d'autres interfaces plus récentes ont plus tard permis de démocratiser ces formidables outils.

Néanmoins, force est de constater que les CPCistes connaissent, et donc utilisent, un nombre limité de ROMs d'extension. Pourtant, il en existe une quantité assez impressionnante ! Le principal obstacle est souvent l'absence de notice ; en effet, s'il est assez facile de trouver les fichiers des images des ROMs à programmer dans la Ramcard, certains outils en ROM, sans leur notice explicative, sont tout bonnement inutilisables !

Or donc, afin de couper court aux ragots du petit blond à lunettes, voici un dossier sur les ROMs. Dans un premier temps, je vais vous présenter la structure matérielle des ROMs d'extension sur CPC. Ensuite, je vous proposerai une sélection des ROMs que je pense intéressantes quoique peu utilisées.

Et pour finir, vous aurez droit à un petit cours sur l'art et la manière de créer vos propres outils en ROM.

Sur CPC, il existe deux grandes familles de ROMs : les ROMs hautes et les ROMs basses. Ces dernières sont les ROMs firmware ; elles contiennent l'OS du CPC et ses extensions les plus intimes. Par défaut, le CPC possède juste une ROM firmware de 16ko. Celle-ci contient toutes les routines de base de l'OS (gestion de l'affichage, du son, du clavier, des entrées/sorties, etc.). Il est possible de placer d'autres ROMs basses, c'est par exemple ce que font la Multiface Two ou les cartouches des CPC+… mais c'est en réalité assez peu intéressant en usage courant. Non, les ROMs véritablement intéressantes, ce sont les ROMs hautes ! Le Romboard¹⁾, la Romcard²⁾, la RamRomBox³⁾ et enfin la Ramcard⁴⁾, sont des interfaces qui permettent d'ajouter de telles ROMs d'extension sur le CPC.

Dans cette famille des ROMs hautes, nous avons trois sous-ensembles. Les ROMs de premier plan, les ROMs de second plan et les sans famille (ou ROMs de données). De base, tout CPC possède une ROM de premier plan : le BASIC. De plus, les CPCs équipés d'une interface disque⁵⁾ possèdent également une ROM de second plan : l'Amsdos (CP/M ROM). À la différence des ROMs basses, les ROMs hautes sont très structurées. C'est ainsi que la ROM CP/M porte le numéro 7 et la ROM BASIC le numéro 0 (nous verrons plus tard que la ROM BASIC a un statut à part avec un numéro “flottant”). Techniquement (et c'est ce que propose la Ramcard), le CPC est capable de gérer 256 ROMs⁶⁾. Néanmoins, le firmware ne sait initialiser automatiquement que les ROMs de second plan portant un numéro compris entre 1 et 15⁷⁾. Concernant les ROMs de premier plan, si elles peuvent avoir un numéro quelconque, toutes celles au delà de 15 devront être consécutives pour être reconnues par le firmware.

Enfin, la ROM numéro 0 (qui contient par defaut le BASIC) a un statut spécial puisque c'est à celle-ci que le firmware passe la main pour gérer le boot du CPC. Il existe d'ailleurs peu de ROMs prévues pour porter le numéro 0.

Ces ROMs là ne sont pas les plus répandues sur CPC. Il s'agit des ROMs capables de prendre complètement en charge le fonctionnement du CPC (en s'appuyant sur le firmware). La ROM de premier plan par excellence est le BASIC que nous avons de base dans tout CPC. Une autre, très connue aussi, est le Hacker. Comme vous devez le comprendre, il s'agit là de ROMs “lourdes”. La majorité des ROMs sur CPC sont des ROMs de second plan.

Ces ROMs là sont en fait prévues pour contenir des bibliothèques d'outils (via des RSX et des vecteurs) pour étendre les commandes du système. Tout le monde connait forcément l'Amsdos. Cette ROM de second plan ajoute la gestion disque au firmware et offre quelques RSX d'extension. A, B, DRIVE, permettent de choisir le lecteur, CPM permet de booter sur une disquette système, REN, ERA sont là pour renommer ou effacer des fichiers, etc.. Mais en fait, les RSX les plus intéressantes pour bien comprendre le principe de l'implémentation de l'Amsdos dans le firmware sont DISC, TAPE et leur dérivés⁸⁾. DISC installe les routines Amsdos pour la gestion des entrées/sorties firmware (via les indirections)… et TAPE remet en place les routines de base du firmware (celles qui s'occupent du lecteur de K7).

Je ne vais pas vous détailler ici le fonctionnement des indirections du firmware qui permettent de telle prouesses, mais sachez que de telles indirections existent pour à peu près tous les modules du firmware (la vidéo, le clavier, etc.). Une ROM peut donc facilement, outre les RSX qu'elle propose, s'imbriquer dans les routines du firmware et offrir une structure unitaire.

Il s'agit des ROMs qui ne sont ni de premier plan, ni de second plan. Ces ROMs sont tout bonnement ignorées par le firmware ! Libre à vous de les gérer à la main comme bon vous semble. En pratique, il existe très peu de ROMs de ce “non-type”. Elles ne contiennent généralement pas de programmes directement utilisables par le CPC, mais plutôt des données ou des routines pour un programme logé dans une ROM typée.

Comme je vous l'ai déjà dit, la ROM numéro 0 a un rôle particulier puisque c'est celle sur laquelle le firmware va booter. La ROM placée en numéro 0 doit donc être capable de tout prendre en charge. De par leur nature, toutes les ROMs de premier plan sont susceptibles d'être installées en numéro 0. Mais, curieusement, il y a aussi des ROMs de second plan qui sont aptes à jouer ce rôle. La ROM CP/M en fait partie : si elle constate qu'elle est installée en numéro 0, lorsque le firmware lui donne la main, elle prend tout en charge et boote sous CP/M. En revanche, placée n'importe où ailleurs, elle se comportera comme n'importe quelle autre ROM de second plan en déclarant la liste de RSX et en ajoutant ses fonctionnalités au firmware.

Le BASIC est notre ROM numéro 0 par défaut. Mais afin de ne pas bloquer l'emplacement 0 et de permettre à une autre ROM de prendre sa place via une extension externe (Romboard, Ramcard, etc.), c'est en fait une ROM balladeuse. Elle ne porte pas le numéro 0 de façon rigoureuse ; elle se positionne en fait sur le premier emplacement libre. Si vous installez une ROM 0, le BASIC portera le numéro 1… s'il y a déjà une ROM 1, il se décalera en 2, etc.. En fait, pour les puristes, la ROM BASIC répond présent à chaque fois qu'elle trouve un emplacement libre.

Le petit blond à lunettes vient à faire une remarque judicieuse… “et qu'en est-il de notre ROM 7 (l'Amsdos) déjà présente sur les CPC à disque ?”. Eh bien, ça se passe beaucoup moins bien. Celle-ci a un numéro statique ! Il est donc tout simplement impossible de placer une ROM numéro 7 externe sous peine de graves conflits. Amstrad a rectifié le tir avec les CPC+ sur lesquels la ROM 7 interne⁹⁾ s'invalide automatiquement si une ROM 7 externe est installée. Mais sur les CPC ancienne génération, la seule solution est de modifier la carte mère. Ceci est assez gênant car la ROM 7 est la ROM disque et il est tout naturel de la faire évoluer avec les nouveaux standards (pour gérer l'ajout d'un lecteurs 3"1/2 ou d'un disque dur par exemple). On peut bien sûr proposer une autre ROM disque qui s'installerait à un autre emplacement mais… malheureusement, de nombreux programmes, lorsqu'ils font des accès disque, ne passent pas par le firmware mais directement par la ROM disque qu'ils supposent être la ROM 7 et pas une autre.

Avant de vous présenter justement les principales ROMs disque disponibles, voyons rapidement comment le firmware lance l'installation des ROMs. Il est en effet important de comprendre ce mécanisme pour savoir dans quel ordre installer ses ROMs pour avoir un fonctionnement optimal. En premier lieu, le firmware s'initialise, configure la RAM (zones entre &0000 et &003F ainsi qu'entre &AC00 et &BFFF), installe tous les modules de l'OS (les interruptions, les events, les tables de conversion des caractères clavier, etc.), et fait bien d'autres choses encore (toutes liées à la mise en service matérielle et logicielle du CPC). Ceci étant fait, le firmware donne la main à la ROM 0. Neuf fois sur dix, la ROM 0 est le BASIC. Il commence alors à s'initialiser, installer des vecteurs en RAM, etc…. puis il demande au firmware d'initialiser toutes les ROMs de second plan. Le firmware va alors installer -en commençant par le numéro 15 et jusqu'au numéro 1- toutes les ROMs de second plan qu'il rencontrera. Lors de cette phase, les ROMs vont une à une réserver leur zone de travail en mémoire, installer leurs indirections et leurs RSX. Vu que le firmware commence par la ROM 15 et finit par le 1, on comprend bien que c'est donc la ROM portant le numéro le plus faible qui est prioritaire sur les autres étant donné qu'elle installe ses indirections et ses RSX en dernier.

Ainsi, si vous avez une ROM disque en numéro 6, elle sera prioritaire sur la ROM CP/M installée en 7. Tous vos accès entrée/sortie passeront par elle et plus par la ROM 7. De même, si vous avez une ROM dépendant d'une autre (par exemple Promerge par rapport à Protext ou Rodos par rapport à l'Amsdos), il faudra lui donner un numéro plus faible que celui de la ROM dont elle a besoin. Sinon, elle ne la verra pas et renverra sans le moindre doute une erreur (pour Promerge ça sera une erreur fatale et la ROM ne s'installera pas puisqu'elle ne sert à rien sans Protext, pour Rodos ça sera juste un avertissement signifiant que les formats de disque de l'Amsdos ne seront pas pris en charge).

Gardez toujours ce principe de priorité en tête. Notamment pour les RSX, s'il y a une RSX HELP dans la ROM 4 et un autre dans la ROM 2, c'est celui de la ROM 2 qui sera appelé par défaut. Mais ça ne veut pas dire que celui de la ROM 4 est perdu ; il est tout à fait possible d'en demander l'accès par certains vecteurs de gestion des ROMs du firmware. Malheureusement, le BASIC ne permet pas cette option, mais certaines ROMs (comme la fameuse Utopia) offrent une RSX (X en l'occurence) qui permet d'accéder à ces RSX non prioritaires.

Voilà, les bases sont posées pour une bonne utilisation des ROMs. Je rentrerai plus dans le détail lorsque nous aborderons l'aspect programmation.

La première ROM qu'il est nécessaire d'installer sur son CPC est souvent une ROM disque, par exemple, consécutivement à l'achat d'un lecteur 3”1/2. En effet, les sévères limites de l'Amsdos sont déjà tristement célèbres : des tables d'allocation de 1ko, 64 entrées d'allocation au maximum, noms au standard 8+3, etc.. Mais cela devient encore plus dramatique avec le format 3”1/2 lorsqu'on se rend compte que l'Amsdos ne sait absolument pas gérer les lecteurs en 80 pistes ou en double face ! Il est frustrant de devoir se limiter à 178ko par disque 3”1/2 alors qu'il peut en contenir plus de quatre fois plus ! Bien sur, il existe des solutions matérielles et logicielles mais elles ne sont pas très heureuses : l'installation d'un pathétique inverseur de face ne permet ni plus ni moins que de doubler la capacité, et un soft comme Copyluck¹⁰⁾ permet de stocker jusqu'à 253ko par face (et d'y accéder sans driver spécial). Même en cumulant ces deux solutions bon marché, on est encore bien loin des 800 à 840ko théoriquement disponibles. D'autant plus que, matériellement parlant, le CPC est parfaitement capable de gérer un lecteur 80 pistes en double face sans le moindre artifice.

La solution est en fait très simple : il faut remplacer cette horrible ROM CP/M qu'Amstrad nous a refourgué d'origine. Il existe de nombreuses ROMs disque ; certaines sont carrément des ROMs de substitution de l'Amsdos (elles sont 99% compatibles mais sont plus complètes) et d'autres s'inscrivent simplement dans la logique des extensions ROM du firmware et viennent “en plus”.

Parados est une ROM prévue pour être installée en ROM numéro 7 à la place de l'Amsdos. Cette ROM gère en effet tout aussi bien les formats Amsdos originels que ses propres formats ainsi que d'autres formats plus exotiques. Son principal atout est qu'elle est compatible Amsdos au niveau matériel. C'est-à-dire que lorsque des programmes mals conçus vont demander un accès au lecteur de disquettes en passant directement par la ROM 7 plutôt que par le firmware, cela fonctionnera ! De tels programmes peuvent donc être stockés sur des disquettes aux nouveaux formats de façon complètement transparente et fiable.

Toutefois, étant donné que tout le monde n'a pas de 6128 plus ou n'est pas en mesure de patcher son CPC ancienne génération pour placer une ROM 7 externe, Parados est également conçue pour être mise ailleurs, en dessous de la ROM 7. Dans ce cas là, Parados va s'installer de la même manière à la place de l'Amsdos vis-à-vis du firmware¹¹⁾, mais les programmes tapant directement en ROM 7 (ce qui est illégal, je le rappelle) ne pourront alors pas profiter des nouveaux formats Parados.

Que nous offre donc cette ROM ? En premier lieu, elle gère parfaitement les lecteurs 3”1/2 grâce à divers formats. Mais en plus, elle intègre un copieur de fichiers (accessible via la RSX DRIVE lancé sans paramètre) assez évolué. Cet outil permet de configurer les divers paramètres de la ROM, de formater, de copier et de gérer vos fichiers sur les disquettes. Je ne vais pas vous faire une notice complète ici, ce n'est pas l'objet, nous allons juste voir les nouveaux formats intéressants qui nous sont proposés.

D'abord, nous avons de nouveaux formats pour nos bons vieux lecteurs 3” : le Parados 40 et l'Ultraform. Nous ne nous intéresserons pas au format Ultraform qui n'apporte rien de plus par rapport au format Parados 40, et qui n'est là que pour la compatibilité avec d'anciens softs de formatage dont bien peu de monde a en fait entendu parler. De plus, le format Ultraform est désactivé par défaut dans les préférences de la ROM Parados car il est en conflit avec le format Romdos dont nous parlerons ci-après. Il est également intéressant de noter que le format IBM, normalement géré par défaut par l'Amsdos, est également désactivé au profit du format Romdos D10… Je ne pense pas que ça gêne qui que ce soit, ce format n'étant en fait là sous Amsdos uniquement pour la compatibilité avec les disquettes du PCW. Or donc, revenons-en à notre format Parados 40. Il rend complètement inutiles les classiques formats SYSTEM et DATA de nos 3” ! Quoique toujours limité à un maximum de 64 entrées pour des allocations de 1ko¹²⁾, il nous offre toutefois 203ko au lieu des 169ko ou 178ko. Les possesseurs de la ROM Parados ont donc tout intérêt à bannir complètement le format DATA. Seul le format SYSTEM peut encore justifier son utilité à cause de ses pistes de boot, mais ça reste des cas très particuliers.

Même si ce format dédié au 3” est bien sympathique, il n'est rien face aux formats désormais disponibles pour les lecteurs 5”1/4 ou 3”1/2. Ceux d'entre-vous qui possèdent un bon vieux lecteur 5”1/4 ou un lecteur 3” à deux têtes pourront utiliser le format Parados 40D. Fini les inverseurs de face manuels qui trainent à côté des lecteurs ! Ce format vous offre un espace linéaire de 396ko, avec 128 entrées et des allocations de 2ko. Sur 3”1/2, c'est encore plus la fête. Même si vous possédez un de ces bons vieux 3”1/2 à simple tête¹³⁾, les concepteurs de Parados ont pensé à vous avec le format Parados 80 : 396ko, 128 entrées et 2ko (par face).

Mais si, comme pour la majorité des CPCistes actuels, un fier lecteur 3”1/2 à deux têtes trône à droite de votre clavier, vous allez vibrer pour les formats Romdos dont la gestion est incluse de base dans Parados. Oubliez la ROM Romdos ou sa version disque Ramdos ; la ROM Parados prend tout en charge et vous offre les formats Romdos D1, D2, D10 et D20. Les formats D1 et D2, forts de leurs 716ko et 712ko, ne sont pas très intéressants face aux très performants formats D10 et D20.

• Romdos D10 : 796ko, 128 entrées, blocs de 2ko.
• Romdos D20 : 792ko, 256 entrées, blocs de 4ko.

Tout cela, sans aucune intervention manuelle sur un interrupteur¹⁴⁾ et de façon complètement transparente… même pour un programme tapant directement en ROM pour peu que Parados soit placée en numéro 7. Alors que le format D10 offre un maximum de place, le D20 est plus adapté aux disquettes devant contenir un grand nombre de fichiers.

Avant de conclure sur Parados, je tiens à vous préciser qu'il en existe deux versions : la 1.0 et la 1.1. Outre un petit bug d'affichage du menu qui a été corrigé, la dernière version intègre la gestion des formats DATA et SYSTEM en mode double face. Non seulement ça ne revêt pas un très grand intérêt face aux autres formats mais, en plus, cela pose un problème de compatibilité avec des disquettes DATA ou SYSTEM formatées à l'ancienne avec un inverseur de face manuel ; elles ne seront plus reconnues correctement par défaut¹⁵⁾.

Pour en finir, voyons maintenant les points faibles. Une fois le logiciel intégré lancé, il n'y a aucun moyen de quitter ; un reset s'impose. Cela se justifie d'une certaine manière car lors des copies la RAM est de toute façon détruite… mais lorsqu'on l'utilise simplement pour changer des réglages, formater ou renommer/effacer des fichiers, il eut été judicieux de permettre un retour au système. Les autres défauts sont les mêmes que ceux de l'Amsdos : il y a un nombre d'entrées limité par disque, la taille des blocs est assez imposante et le nom des fichiers est au standard 8+3. Nous devons également nous contenter des USERs pour triers nos fichiers ; vu la taille des disques 3”1/2, l'implémentation de répertoires n'aurait pas été du luxe. Mais, dans l'ensemble, cette ROM est un must à installer impérativement, même si nous n'avez pas de lecteur 3”1/2 car le format Parados 40, le logiciel intégré (qui gère les DK'Tronics), et les accès disque accélérés sont déjà très intéressants.

Il s'agit là d'une véritable ROM disque (et même plus) qui ajoute toute une nouvelle logique de fonctionnement au système. On est bien loin de Parados et de son principe d'amélioration de l'interface disque dans l'esprit de l'Amsdos. En premier lieu, vous devez comprendre que la ROM Rodos n'est plus du tout une ROM de substitution de l'Amsdos mais bel et bien une nouvelle ROM disque. D'ailleurs, Rodos ne sait absolument pas lire les formats Amsdos ; si vous désirez continuer à les utiliser, vous devrez laisser une ROM CP/M ou Parados intallée sur votre système (Rodos vous avertit lorsqu'il ne trouve pas de ROM compatible CP/M lors de son initialisation et lorsqu'il se retrouve nez à nez avec un format de disquette qui n'est pas de son ressort).

Il y a deux conséquences directes à ce que cette ROM vienne en plus et non à la place de l'Amsdos : elle a sa propre zone de travail et nécessite des accès régulier au système d'exploitation (exit les programmes qui tapent dans la RAM ou la ROM 7 sans se poser de questions), mais, en revanche, elle ne souffre plus des contraintes qui minent l'Amsdos et nous offre une gestion des disques et du système digne des ordinateurs d'une toute autre gamme. Les contraintes liées au premier point sont à peu de chose près les mêmes que celle que j'ai décrites dans le cadre d'une utilisation de Parados ailleurs qu'en ROM 7… ce qui ne remet nullement en cause l'intérêt de Rodos, notamment pour le développement.

Le petit blond à lunettes commence à lorgner par dessus mon épaule pour lire mes notes… c'est bon, j'y viens ! The Rodos System se présente sous la forme d'une simple ROM de second plan de 16ko et contient en fait deux modules d'extension : Rodos à proprement parler, qui s'occupe du nouveau format des disques, de la gestion des lecteurs¹⁶⁾ et de la gestion étendue des fichiers (index, spooler) ; et puis il y a RECS, qui regroupe tout un pack de commandes plus intéressantes les unes que les autres, comme la présence d'un buffer d'impression ou la gestion d'un shell et de batch files, mais aussi un contrôle logiciel de la priorité d'installation des ROMs et du boot du CPC.

Je ne vais pas tout vous détailler ici car ça serait vous noyer sous des flots interminables de paroles ! Je vais donc m'attacher à vous décrire le nouveau format proposé et ce dont il est capable. Rodos offre donc un nouveau format de disque : le format Rodos (pas compliqué à retenir pour le coup). Ce format est capable de gérer n'importe quel support simple ou double face pour un nombre de piste quelconque. Sur une face 3”, il vous permettra de loger jusqu'à 210ko et atteind allègrement les 840ko sur 3”1/2… pour le moment, c'est bien, mais rien d'exceptionnel. Là où ça devient plus intéressant, c'est qu'il n'y a plus de limite quant au nombre maximum de fichiers contenus sur le disque, que les tables d'allocation sont réduites à 512 octets, que les noms des fichiers sont au format long (avec majuscules et minuscules), qu'on peut avoir des répertoires, des liens, des noms de volume et… cerise sur le gâteau, une gestion multi-utilisateur des droits d'accès aux fichiers ! Et ce n'est pas tout ! Les accès disque sont largement plus rapides que sous Amsdos (ou même Parados) et les noms des lecteurs sont redéfinissables… libre à vous de nommer le lecteur 3” en E, le lecteur 3”1/2 externe en C et… le ramdisk en A ! Eh oui, car non contente de gérer les lecteurs connectés au FDC d'origine du CPC, Rodos est capable d'appliquer son format à n'importe quel périphérique de stockage ! D'origine Rodos possède le driver pour gérer la mémoire étendue compatible DK'Tronics comme un disque (ramdisk) mais vous permet d'en installer simplement des nouveaux. Si votre périphérique additionnel est à base de FDC, vous aurez juste à donner l'adresse du port d'accès (Rodos s'occupe ensuite de tout), si c'est un périphérique complètement nouveau (Memcard, IDE-Card, CPC-ISA Card, etc.) il vous faudra indiquer à Rodos où se trouvent les routines de gestion de base (lecture/ecriture secteur et formatage de piste).

Il ne s'agit là que des aspects “devices” et “filesystem”, Rodos gère bien plus de choses… et tout ça tient dans 16ko ! Le petit blond à lunettes me fixe de son regard vicieux : “si elle est si géniale… pourquoi personne ne l'utilise ?”. Oui, effectivement, il faut avouer que Rodos souffre d'un problème d'ergonomie. La syntaxe des RSX est très rude et il est véritablement impossible de mettre en oeuvre certaines fonctions (comme le formatage ou la configuration des lecteurs) sans avoir le manuel sous les yeux. Ceci étant, le manuel est très complet, bien rédigé, et existe de plus en version française. Quant au problème d'ergonomie des RSX d'origine il suffirait en fait de créer une nouvelle ROM qui servirait de passerelle vers les commandes de Rodos en offrant une syntaxe et une ergonomie plus avantageuses.

En résumé cette ROM est certainement la meilleure ROM d'extension qui existe sur CPC tant par sa performance que par la diversité des fonctions qu'elle offre, bien au delà de sa fabuleuse gestion des disques. Tout ce qui lui manque, c'est un peu d'ergonomie, mais l'écriture d'une ROM fille résoudrait rapidement ce problème. Je vous rappelle le format Rodos :

• Disquette 3” : jusqu'à 210ko par face.
• Disquette 3”1/2 : jusqu'à 840ko par disquette.
• N'importe quel autre support : jusqu'à 32Mo.

Dans chacun de ces formats vous avez bien sûr les noms longs, les répertoires, les noms de volume, les liens, etc. et l'allocation de base est toujours de 512 octets pour un nombre de fichiers illimité ! De plus, vous avez droit à 255 lecteurs simultanés ! Ce bijou nous vient de chez Romantic Robot, tout comme la Multiface Two.

En digne et juste complément, nous allons maintenant nous intéresser aux principales ROMs d'outils disponibles sur CPC pour le développement et plus si affinité. Nous ne parlerons ici que des véritables ROMs, c'est-à-dire des programmes réellement conçus pour fonctionner en ROM et non des nombreuses fausses ROMs d'outils qui circulent et qui ne consistent qu'à utiliser la ROM comme un espace de stockage avant de recopier bêtement tout le programme en RAM pour l'exécuter.

La ROM d'outils qui s'avère rapidement indispensable à tout CPCistes souhaitant bidouiller un petit peu sa machine est sans conteste Utopia. Il s'agit d'une ROM de second plan qui ajoute au système toute une série de RSX aussi bien pour manipuler votre mémoire et vos disquettes que pour vous assister dans l'élaboration de vos créations en BASIC. De plus, la plupart des RSX proposées par Utopia offrent une assistance à la saisie des paramètres ! Plus besoin de connaître par coeur la syntaxe exacte ! Tapez votre RSX sans aucun paramètre et Utopia vous les demandera gentiment un par un. Ceci vaut également pour les commandes par défaut de l'Amsdos qu'Utopia prend en charge comme REN ou ERA.

Je vois que le petit blond à lunettes est de plus en plus excité à l'idée d'utiliser tous ces outils… aussi, nous allons sans plus attendre faire un rapide tour d'horizon des diverses RSX additionnelles d'Utopia.

Une partie importante des RSX est consacrée à la gestion des fichiers et plus largement des disquettes. En effet, force est de constater que ce que nous propose la ROM Amsdos par défaut est assez minimaliste et que l'on doit bien souvent avoir recours à des outils externes comme Discologie pour des opérations aussi simples que protéger un fichier en écriture ou formater une diquette. Oubliez tout ça ! Avec Utopia la plupart des opérations disque deviennent possibles directement depuis le BASIC ! Voici un petit mémo des RSX liées à la gestion disque qui vous donnera une idée de toutes les opérations directement accessibles :

ACCESS : modifie les droits d'accès sur les fichiers (protégé/système).

CAT : identique au CAT du BASIC sauf qu'il a besoin de moins de mémoire (fini les ”MEMORY FULL” lorsqu'on travaille avec un himem bas !).

COPY : permet tout simplement la copie de fichiers.

DEDIT : permet d'éditer physiquement les secteurs d'une disquette ! C'est pratiquement l'équivalent de l'éditeur de secteurs de Discologie… sauf qu'il est disponible sous BASIC ! très pratique pour faire du “catalogue art” par exemple.

DELETE/ERA : identique à la commande ERA de l'Amsdos.

DISCCOPY : copie rapide de disquettes.

DISCTEST : vérification rapide de disquettes.

DUMP : liste un fichier en hexa directement depuis la disquette.

FORMAT : formate une disquette.

INFO : liste les type, adresse de chargement, longueur et adresse d'exécution des fichiers (c'est un CAT détaillé).

LOAD : charge un fichier de type quelconque (même ASCII !) à une adresse spécifiée.

REN : identique au REN de l'Amsdos.

RUN : identique au RUN”fichier” du BASIC sauf que le système n'est pas réinitialisé.

SAVE : sauve un fichier binaire à partie de données en mémoire.

SAVEA : sauve un fichier ASCII (!) à partir de données en mémoire.

SPOOL/SPOOLOFF : active/désactive la capture de l'affichage vers un fichier ASCII.

TYPE/LIST : liste un fichier ASCII sans/avec les numéros de ligne directement depuis la disquette.

VERIFY/VTEXT : compare une zone mémoire avec le contenu d'un fichier et affiche les/la différence(s).

En complément de tous les outils disque, Utopia offre également divers outils particulièrement adaptés aux programmeurs en BASIC. Toutefois, comme le fait justement remarquer le petit blond à lunettes, le BASIC servant très souvent de “shell” pour le développement en assembleur, la plupart de ces outils sont également très utiles aux codeurs !

ARRAYS : liste les tableaux de variables existants et leur taille.

C : effectue des calculs en 16 bits non signé.

CALL : lance une routine assembleur avec le choix de la valeur des registres Z80 en entrée et l'affichage de leur contenu en sortie.

FIND : cherche une chaine de caractères dans le programme BASIC.

FN : affiche la liste des fonctions BASIC définies par l'utilisateur (commande DEF FN).

LINK : réinitialise tous les pointeurs BASIC (permet entre autre de déprotéger un programme BASIC protégé).

MDUMP/MEDIT : liste/édite la mémoire en hexa.

MOVE : déplace des lignes dans un programme BASIC.

NOKEYS : efface toutes les définitions de touches (KEY DEF).

NORSX : désinstalle toutes les RSX RAM (aucun effet sur les RSX ROM). Très pratique lorsqu'on est en train de développer des RSX !

REPLACE : cherche et remplace une chaîne de caractères par une autre dans un programme BASIC.

STATUS : affiche l'état des allocations mémoire des diverses structures du système (symbols, himem, etc.).

TOKENS : affiche la configuration courante des définitions de touches.

VARS : affiche la liste des variables, leur type et leur contenu.

Utopia contient enfin une série d'outils liés à la gestion du système dans sa globalité.

CDUMP/GDUMP : impression du contenu de l'écran en mode caractère/graphique (une bête copie d'écran).

HELP : liste les ROMs installées et leur allocation mémoire. Avec un numéro de ROM en paramètre, donne la liste des RSX de la ROM.

HELPR : liste les RSX installées en RAM.

PRINTON/PRINTOFF : active/désactive la redirection de l'affichage vers l'imprimante.

ROMOFF/ROMON : reboote le CPC sans/avec les ROMs spécifiées.

U : lance une RSX d'Utopia (éventuellement avec ses paramètres s'ils sont spécifiés) désignées par son nom. Ceci permet d'accéder aux RSX d'Utopia qui ont été surchargées par celles d'une autre ROM ou par des RSX installées en RAM.

X/XROM : lance la RSX désignée par son nom dans la ROM de son choix.

Enfin, Utopia configure par défaut des raccourcis clavier sur les touches de fonctions couplées à CONTROL. Ces raccourcis assez bien pensés permettent un accès direct aux commandes qui sont effectivement souvent utilisées comme CAT, MODE 2, LIST, ERA,”*.BAK”, STATUS, et pour les utilisateurs du kit de développement Arnor, PROTEXT¹⁷⁾ et M,2¹⁸⁾ !

En conclusion on peut dire qu'il s'agit vraiment d'une ROM incontournable pour tout CPCiste qui utilise vraiment son CPC pour bidouiller ou programmer.

Indépendamment de son assembleur dont nous parlerons plus loin, cette ROM qui fait partie du fameux kit de développement Arnor¹⁹⁾ se révèle très intéressante pour son moniteur/debugger Z80. En effet, il permet de définir simplement les conditions d'exécution du code à tester et d'y placer divers types de breakpoints afin d'en observer judicieusement le fonctionnement. De plus, comme il s'agit d'une ROM parfaitement intégrée, elle n'a besoin que de quelques octets de RAM pour fonctionner ce qui lui donne un avantage certain par rapport aux autres moniteurs qui ont besoin de se charger en RAM. Son utilisation depuis le Hacker rend également de fiers services.

Avant de vous donner une rapide description des commandes (RSX) du moniteur/debugger de Maxam, je vais vous en expliquer le principe. Il faut vous imaginer que le programme que vous allez tester est exécuté dans un espace de travail parallèle. Grâce aux commandes du debugger vous pouvez définir la configuration de cet espace de travail (valeur des registres, breakpoints, etc.) et vous avez la possibilité de commuter entre l'espace d'exécution du programme et le debugger (et inversement) très simplement en modifiant éventuellement les conditions d'exécution entre temps. Ceci étant bien à l'esprit, vous allez trouver ci-dessous la liste des commandes disponibles.

AA/AF/BC/DE/HL/IX/IY/PC : charge la valeur passée en paramètre dans le registre du Z80 correspondant. Si le paramètre est omis, alors ces RSX affichent simplement la valeur en cours de tous les registres et la prochaine instruction qui sera exécutée.

REGS : affiche la configuration détaillée de l'espace de travail : valeur de tous les registres du Z80, mémoire pointée par chacun des registres, état des flags et des commutations mémoire, prochaines instructions, etc.

BR : place un breakpoint à l'adresse spécifiée en paramètre (8 breakpoints au maximum). Lors que le programme arrivera à cette adresse, il sera interrompu et le debugger affichera son état courant de la même manière que la commande REGS.

TB : place un breakpoint temporaire à l'adresse spécifiée en paramètre (un seul breakpoint de ce type est possible). Ce type de point d'arrêt se comporte exactement de la même manière que ceux positionnés via la commande BR hormis le fait qu'il ne s'active qu'au premier passage du programme.

CB : annule le breakpoint de l'adresse spécifiée en paramètre.

CAB : annule tous les breakpoints.

DB : liste les breakpoints.

QB active le mode rapide des breakpoints (c'est le mode par défaut). Dans ce monde, l'état courant du programme interrompu est affiché aussitôt un breakpoint rencontré.

WB : active le mode d'attente des breakpoints. Dans ce mode, le debugger attend que l'utilisateur presse une touche avant d'afficher l'état courant du programme interrompu.

BRKOFF : désactive la gestion des breakpoints.

BRKON : active la gestion des breakpoints (état pas défaut).

J : exécute un programme en mode debug ; c'est à dire avec la gestion des breakpoints et l'utilisation de l'espace de travail (valeur des registres et pile utilisateur activées). Si une adresse est spécifiée en paramètre, elle sera chargée dans PC avant de passer en exécution. Si aucune adresse n'est spécifiée, alors la valeur courante de PC dans l'espace de travail sera utilisée. Par défaut PC est placé à &33 (il y a un RET à cette adresse) ; il est en outre automatiquement positionné au dernier ORG rencontré par l'assembleur de Maxam (commandes ASM, ASSEM ou ASSEMBLE).

O : reprend l'exécution d'un programme interrompu par un breakpoint. Typiquement cette commande est très semblable à J sauf qu'elle n'effectue pas les initialisations de celle-ci relatives à la gestion de la pile. J ne doit pas être utilisé pour reprendre l'exécution d'un programme interrompu ; en revanche, si vous utilisez O plutôt que J pour lancer l'exécution initiale d'un programme en mode debug, cela fonctionnera car le debugger détecte qu'il s'agit d'une première exécution et O est alors parfaitement équivalent à J. Vous pouvez donc utiliser systématiquement O plutôt que J pour lancer vos programmes fraichement assemblés.

DI/DIF : désassemble à l'écran ou dans un fichier.

LI/LIF : liste la mémoire à l'écran ou dans un fichier.

M : lance le moniteur de Maxam. Ce moniteur est assez complet et intègre des outils pour éditer la mémoire, déplacer les blocs de mémoire, manipuler les commutations de ROM, désassembler et même reloger des programmes assembleur.

MSH/MSL : place l'écran système en mémoire haute (&C000) ou basse (&4000). Le choix de la configuration vidéo du système s'avère souvent être un outil très pratique pour étudier des programmes prévus pour s'exécuter en &C000-&FFFF (ce qui est le cas des ROMs hautes).

Voilà, nous avons fait le tour des principales commandes du moniteur/debugger de Maxam 1½. Il va de soi que n'importe quelle commande est utilisable à n'importe quel moment, même après un breakpoint avant de relancer l'exécution du programme (commande O).

La ROM de Maxam contient également un assembleur très souple et parfaitement respectueux du système. Celui-ci peut-être invoqué grâce à quatre commandes et gère une multitude de directives d'assemblage. Voyons en premier lieu les commandes d'assemblage.

ASM : assemble le code stocké dans l'éditeur de Protext. Protext fait en effet également partie du kit de développement Arnor, et Maxam sait en tirer profit. La valeur de PC pour l'espace programme est placée automatiquement au dernier ORG rencontré lors de l'assemblage.

TASM : identique à ASM sauf que l'assembleur ne fait pas de résolution des symboles. C'est très pratique pour vérifier la syntaxe d'un module (include) dépendant d'autres fichiers d'assemblage sans avoir à tout compiler systématiquement.

ASSEMBLE : assemble le code stocké sous forme de remarques (REM ou ') dans le programme BASIC. Des pointeurs de variables BASIC peuvent être passés en paramètre ce qui permettra de les récupérer ou de les affecter grâce aux directives d'assemblage GET et PUT.

ASSEM : identique à ASSEMBLE hormis le fait qu'aucun affichage n'est généré pendant l'assemblage.

Tout ceci nous amène tout naturellement à nous demander quelles sont les directives d'assemblage dont nous disposons sous Maxam. Comme nous avons pour habitude de vous gâter, j'ai pris mon courage à deux mains et je vous livre en livre tout de suite la liste avec la petite description qui va bien à chaque fois.

ORG : c'est la directive de base, commune à tous les assembleurs, qui permet de définir l'adresse où assembler votre code source. Si un seul paramètre est spécifié, alors le code est généré pour cette adressé et y est également stocké. Si deux paramètres sont fournis, alors le code est généré pour la première mais stocké à la seconde.

LIMIT : permet de spécifier une adresse limite au-delà de laquelle on ne veut pas assembler. Par défaut limit est fixé au HIMEM et toute tentative d'assemblage au dessus du LIMIT renverra un “CODE LIMIT EXEEDED”.

CODE/NOCODE : désactive/réactive le pokage en RAM du code assemblé. Ces directives sont très utiles lorsque ous avez des programmes relativement complexes dans lesquels vous devez évaluer des pseudo-structures sans pour autant qu'elles ne représentent du code à assembler effectivement.

END/STOP : cesse l'assemblage de tout le programme ou de l'include en cours.

DB/DEFB/DEFM/BYTE/TEXT : poke des octets. Ces octets peuvent être fournis sous forme de nombres ou de chaînes de caractères.

DW/DEFW/WORD : poke des words.

DS/DEFS/RMEM : réserve des octets en mémoire. Le première paramètre représente le nombre d'octets et le second la valeur à mettre dans la zone réservée. Si la second paramètre est omis, alors des zéros seront pokés.

STR : poke une chaîne de caractères avec le bit d'arrêt (bit 7) automatiquement positionné sur le dernier caractère (les noms de RSX sont à stocker selon ce formalisme par exemple).

IF/IFNOT/ELSE/ENDIF : permet de faire de l'assemblage conditionnel. Les IF peuvent être imbriqués jusqu'à 10 fois ce qui est assez énorme et ne représente pas réellement une limite.

IF1/IF2 : renvoie TRUE lors de la passe d'assemblage 1 ou 2. Ceci permet de faire des assemblages conditionnels différents selon que l'assembleur est en train d'évaluer les expressions (passe 1) ou de faire la résolution des symboles et de poker le code en mémoire (passe 2).

READ : permet de faire une inclusion d'une source depuis une autre. Très pratique pour rendre son code modulaire et assembler des programmes qui ne tiennent pas en mémoire. Il peut y avoir autant de READ que vous le voulez dans un source ; en revanche, ils ne peuvent pas être imbriqués.

WRITE/CLOSE : permet de sauver le code assemblé situé entre les balises WRITE/CLOSE dans un binaire sur disque.

NOLIST/LIST : désactive/réactive la sortie écran du résultat de l'assemblage. Dans tous les cas, les messages d'erreur sont affichés.

LIST F : active l'écriture d'un journal du résultat de l'assemblage dans un fichier ASCII (dont le nom est spécifiés en paramètre).

PRINT : affiche un texte. Ce texte est une chaîne de caractères dans laquelle deux caractères d'échappement sont disponibles : $ et &. Immédiatement suivis du nom d'une variable, ceux-ci permettent son affichage en décimal ou en hexadécimal au milieu de la chaîne.

PAUSE : l'assembleur fera une pause à cet endroit là et attendra que vous pressiez une touche pour continuer.

DUMP : affiche la table des symboles. Extrêmement pratique d'autant plus que grâce à la directive LIST F cette table peut-être directement stockée dans un fichier ASCII.

EQU/LET : définit une constante ou une variable de compilation. Les constantes sont fixées une fois pour toute pour toute la phase d'assemblage alors qu'une variable peut-être réattribuée (très pratique en conjonction avec NOCODE pour définir des structures de données dynamiquement allouées).

GET/PUT : permet de manipuler les variables passées en paramètre via les commandes ASSEMBLE ou ASSEM. GET sert à récupérer les valeurs de variables BASIC en paramètre et PUT sert à leur attribuer une nouvelle valeur. Ceci permet de faire des “makefiles” en BASIC.

BRK insére un breakpoint en dur dans le programme. Ce breakpoint se comporte de la même manière que ceux définis de façon dynamique à l'aide des RSX du debugger mais sont directement inclus dans le code assemblé.

LIST P/PLEN/PAGE/TITLE/WIDTH : ces directives sont dédiées au formatage de la sortie sur imprimante du résultat de l'assemblage. D'un commun accord avec le petit blond à lunettes, nous avons décidé de ne pas approfondir.

Concernant les noms de label, il n'y a ni limite de nombre, ni limite de longueur. Les labels ont les mêmes statut que les constantes (définies par EQU) et peuvent être utilisés de la même manière : valeurs pour les instructions assembleur, attribution pour des variables de compilation (LET) ou des variables BASIC (PUT). Comme dans la plupart des autres assembleurs, le symbole “$” désigne l'adresse d'assemblage en cours et peut-être utilisé comme un label.

Pour les valeurs numériques, l'assembleur prend par défaut des valeurs décimales. Pour le binaire la valeur devra être précédées d'un ”%” ; un ”&” ou un ”#” annonce quant à lui un nombre en hexadécimal. Les opérations arithmétiques et logiques sont possibles dans les paramètres des instructions et des directives mais aucune gestion des priorités d'opération n'est effectuée, donc attention.

Les directives ORG et LIMIT peuvent être utilisées plusieurs fois dans un même code source et acceptent comme toutes les autres directives aussi bien des valeurs que des constates ou des variables en paramètre.

J'espère que cette description assez complète (mais qui n'a pas non plus pour objectif d'être un didactitiel) vous aura donné une bonne idée des possibilités de Maxam qui sont sans équivalent sur CPC. Ceci étant… un bon moniteur/assembleur ne fait pas tout ; il faut un éditeur ergonomique pour le rendre réellement agréable à utiliser. Certes Maxam est utilisable depuis le BASIC, mais l'écriture des codes sources dans les programmes BASIC, même si elle est facilitée par diverses RSX, n'en demeure pas moins fastidieuse ! Heureusement, Protext est là ! En pratique le BASIC sert pour écrire de petits codes liés à la gestion de la compilation et de la mémoire (des pseudo-makefiles) alors que Protext sert réellement à l'édition des codes sources.

Contrairement à Maxam 1½ et Utopia, Protext n'est pas uniquement disponible en ROM. Il existe en effet diverses versions disque (sous Amsdos, sous CP/M ou même sous AmigaOS ou MS-DOS). Toutefois, comme nous sommes ici dans une dossier consacré aux ROMs, vous l'avez deviné, nous ne parlerons que de cette version bien que la plupart des fonctionnalités soient rigoureusement les mêmes pour toutes les versions.

Eh bien, il s'agit d'un éditeur de texte hautement configurable disposant également de fonctions de traitement de texte. En pratique, Protext a deux modes d'édition : le mode “program” et le mode “document”. Dans le premier mode, vous pourrez éditer confortablement n'importe quel document ASCII (un code source assembleur ou C par exemple). Dans le deuxième mode, vous pourrez agencer votre texte en vue de l'imprimer comme n'importe quel traitement de texte. À titre de comparaison, Protext est nettement supérieur à Semword pour faire du traitement de texte ; en revanche, Textomat lui reste très largement supérieur (multi-colonnage, détourage, impression proportionnelle, impression circulaire, etc.).

Par ailleurs, contrairement à Semword ou Textomat, Protext est un éditeur à l'ancienne avec un mode édition et un mode commande (on passe de l'un à l'autre à l'aide de la touche ESC). Si cela peut paraître rébarbatif au premier abord, c'est pourtant ce qui fait de Protext le meilleur éditeur de texte sur CPC ! En mode commande, vous avez non seulement accès à toutes les fonctions internes de Protext, mais également à toutes les RSX comme si vous étiez sous un shell (comme sous le CLI de Rodos). Dès lors, vous avez accès depuis Protext à toutes les commandes de toutes les ROMs.

Il s'agit d'un éditeur de texte plus que complet. Vous pourrez faire avec Protext tout ce que vous faire avec un éditeur de texte moderne : rechercher et remplacer des chaînes, déplacer/copier/coller des bouts de texte, importer/exporter sur disque tout ou partie de texte, placer des repères, etc.. En résumé, on peut dire que vous avez absolument tout à part l'indentation automatique ou la colorisation des codes sources (ce qui est rigoureusement inutile pour de l'assembleur). Protext charge et sauve des fichiers ASCII tabulés standards : il est donc compatible avec pratiquement tout le mode (y compris l'éditeur intégré de Maxam 1.1x). Lors de l'utilisation, le texte en cours est stocké dynamiquement en mémoire centrale entre le programme BASIC et le HIMEM : 100% OS-friendly.

Protext est un bon traitement de texte… mais certainement pas le meilleur. Il permet de mettre simplement en œuvre des mises en page simples et est idéal pour rédiger des lettres, des documentations, ou de petits livres. Il gère la pagination, le vis-à-vis des pages, les entêtes et pieds de page, les polices de caractères, la justification et les marges, tous les types de tabulations, etc.. Nous l'utilisons par exemple pour tout ce qui concerne notre courrier lié Quasar CPC. Il est extrêmement configurable et il est facile de se faire soi-même le drivers adapté à son imprimante.

En ce qui concerne l'utilisation des polices de caractères et des effets graphiques (gras, italique, souligné, exposant, indice), Protext fonctionne comme tous les autres traitements de texte : on positionne ses balises à la main. Ce n'est certes pas très ergonomique par rapport à ce qui se fait maintenant, mais il est possible de masquer/montrer les divers codes de contrôle ce qui permet d'avoir une prévisualisation très proche de ce que donnera l'impression. La plupart des autres traitements de texte (comme Textomat) imposent de faire un “aperçu avant impression” dans ce cas. En revanche, comme c'est d'ailleurs le cas pour tous les autres traitements de texte sur CPC, Protext n'est absolument pas WYSIWYG.

Comme le fait si justement remarquer le petit blond à lunettes, on peut conclure en disant que Protext est un excellent éditeur de texte (sans doute le meilleur sur CPC) et un bon traitement de texte (mais toutefois moins puissant que Textomat). Mais protext a une botte secrète : ses plugins ! En effet, Protext est modulaire et il existe un bon nombre d'add-on qui lui ajoutent diverses fonctionnalités. Certains sont également en ROM alors que d'autres sont simplement des drivers disque.

Il s'agit là d'une ROM d'Arnor qui ajoute diverses fonctions à Protext. En premier lieu, elle améliore le monde commande en y ajoutant la copie en ligne (comme sous BASIC avec shift/flêches/copy) ainsi que diverses commandes comme SPLIT (pour découper un fichier sur disque en plusieurs morceaux), CALC (pour effectuer des calculs en ligne), etc.. Ensuite, elle exploite les 64ko supplémentaires des 6128 (ou 464/664 étendus) pour y loger un deuxième document : il est alors possible d'éditer deux sources/textes en même temps sous réserve de ne pas utiliser les 64ko de bank additionnels pour autre chose. Enfin, elle ajoute au traitement de texte les fonctionnalités d'impression circulaire telles qu'elles sont disponibles dans Textomat.

Cette ROM (qui tout comme Protext et Promerge existe aussi en version disquette) n'a d'intérêt que pour la fonction traitement de texte de Protext. Comme son nom l'indique, elle ajoute les fonctions de correction orthographique via un dictionnaire configurable qui devra être stocké sur disquette. En pratique, l'usage de ce dictionnaire est assez similaire à celui de Semword.

Il ne s'agit plus ici d'extensions de Protext disponibles sous format ROM, mais exclusivement sur format disque. Ces modules sont d'ailleurs plus spécifiquement destinés à la version disque de Protext quoiqu'il soit possible de les utiliser avec la version ROM. Protype ajoute la gestion des polices graphiques au mode traitement de texte de Protext : ce qui permet des impressions beaucoup plus élaborées. Quant à elle, Pro-ext est une solution encore plus aboutie puisqu'en plus de permettre l'utilisation de polices graphiques, elle permet l'insertion d'images dans les documents Protext ! Ceci est assez unique sur CPC et fait de protext un outil extrêmement puissant. De plus, ce module intègre un éditeur de polices graphiques et d'images.

Cette extension permet ni plus ni moins que d'utiliser Protext dans l'environnement graphique DES ! DES (qui tient sur deux ROMs) est un environnement graphique pour CPC. En pratique son intérêt est assez limité (rien ne vaut un bon shell pour un maximum d'efficacité) mais c'est un outil ludique assez impressionnant que je vous conseille de tester d'autant plus qu'il ajoute aussi la visualisation WYSIWYG à Protext.

Voilà, nous en avons terminé avec cette rapide présentation des principales ROMs pour CPC !