______________________________________________________________________________ ---- Trackmo-DOS v3.0 ---- par Emmanuel MARTY (Poison of NOVA) Date de Release : 20 janvier 1993 Documentation française ______________________________________________________________________________ I - Introduction et généralités La programmation d'une démo est un sport à part entière sur Amiga. La forme la plus courante et aussi la plus sympa de ces démos, actuellement, est la 'trackmo', autrement dit une démo qui se charge au fur et à mesure de son déroulement, et qui donc permet tous les délires sans se limiter à la taille de la mémoire. Pour le programmeur, le coder, de ces fameuses trackmos, la vie est dure... Outre le fait qu'il doive bosser sur la démo elle-même, les effets, le design, etc., il faut également qu'il prévoie un système de chargement pour les différentes parties de sa démo. La première possibilité est bien entendu d'utiliser le DOS, mais cette technique, outre le fait qu'elle n'est pas toujours bien vue, a pas mal d'inconvénients, notamment le fait qu'il est facile pour n'importe quel lamer de récupérer les données de la démo (sauf si elles sont compactées, et encore...), de plus, le DOS n'est pas très rapide à charger les fichiers ; et enfin le programmeur doit faire face à un certain nombre de problèmes au niveau de la cohabitation entre le DOS et sa démo, ce qui demande une certaine connaissance du système d'exploitation pour ne pas faire trop de conneries. Donc, oublions le DOS. La deuxième méthode, qui se rapproche dêja un peu de que ce je tente (lourdement) d'introduire ici, est de placer les fichiers directement sur la disquette, et de démarrer très simplement du boot, en chargeant la démo au fur et à mesure, soit avec le trackdisk.device (ce qui pose les mêmes problèmes de connaissance du système que le DOS), soit carrément avec une routine de trackload, qui, si elle n'est pas d'une simplicité lumineuse à réaliser, permet de faire ce que l'on veut.. Mais bon, l'utilisation d'une routine de trackload n'est pas à la portée de tout coder (le format de codage des disquettes sur Amiga (le fameux codage 'MFM') n'est pas vraiment un plaisir à utiliser), et de toute façon, trackload ou trackdisk, sauver les différents fichiers que doit charger la démo sur des pistes est franchement ennuyeux, d'autant plus que cela peut être source d'erreurs (on n'écrit pas la bonne longueur, ou on n'écrit pas au bon endroit, etc.) ; il faut également marquer quelque part à quelle pistes et quels secteurs correspondent tel fichier, si c'est sur un papier et qu'on n'est pas trop ordonné on risque de le perdre.. Bref aucune des méthodes citées ne convient à un programmeur humain normalement constitué qui veut garder son calme, et se concentrer sur la programmation des effets de sa démo plutôt que sur une routine de bas-niveau totalement ininteréssante qui s'occupe de charger les différentes parties... Comme je suis moi-même à-peu-près humain et programmeur, et que j'ai dêja rencontré le problème de la réalisation d'une trackmo (ladite trackmo est en attente depuis environ un an pour un problème de graphismes, mais ce n'est pas le sujet), j'ai décidé de me programmer un utilitaire pour résoudre une fois pour toutes ce problème de trackload tout en restant suffisamment transparent à l'utilisation ; mais après discussion avec de nombreux coders (y compris des personnes très connues), je me suis rendu compte que la plupart galèrent à écrire "à la main" les différentes données à coup de trackdisk, comme expliqué plus haut ! Ce qui m'a donc amené à sortir l'utilitaire que je me destinais au départ, en y apportant des améliorations successives, pour finalement arriver aujourd'hui à la version 3.0. Je ne veux pas insinuer que je suis arrivé au top (j'ai encore quelques idées qui vont occuper mes soirées d'hiver !) mais disons que s'il n'existait pas, il faudrait l'inventer... Ceci dit, je sais que la technique qui est la raison d'être du programme et que je vais développer tout au long de ce qui est censé être une documentation a dêja été utilisée dans certaines démos (comme les routines d'Hornet/ALCATRAZ "Odyssey", de Sim/RAZOR 1911 "Voyage", pour prendre des productions connues) et la majorité des jeux, mais aucun programme offrant cette technique a tous les coders n'avait été écrit (il paraitrait que Silents aurait sorti récemment un programme ayant la même vocation (pompe! pompe!), il faut que je me renseigne...), il était donc temps de le faire. La méthode retenue a les avantages du DOS et du Trackload sans leurs inconvénients majeurs. Elle consiste donc à sauver les fichiers directement sur des pistes (mais avec un programme approprié - qui fait ce transfert de facon transparente pour vous, à la manière d'un DiskMaster - dont on parlera plus loin), et à les identifier non pas avec des pistes et secteurs (à cause du bordel évoqué plus haut), mais tout simplement avec des noms de fichiers, comme sous AmigaDOS. C'est donc le but de cet utilitaire, vous permettre de créer des disquettes dans un format spécial, qui permet la sauvegarde de données sur des pistes en les identifiant avec des noms, c'est le but du programme que je designerai désormais sous le nom de "gestionnaire" ; puis, évidemment, de permettre de récupérer ces données grâce à une sorte de système d'exploitation, le TrackmoDOS lui-même (qui offre même la possibilité de vous gérer la mémoire, de vous fournir des renseingements sur le hardware, et d'autres choses encore, mais nous verrons cela au chapitre 3) ; et, enfin, de debugger vos démos en "live" grâce à un moniteur, le T-MON ou TrackmoDOS Monitor (qui a été quelque peu bouleversé, je dis ça pour les afficionados de mon programme), qui peut en effet intervenir au moindre plantage de votre démo, ou par simple appel de votre part, alors que l'AmigaDOS n'existe plus (j'ai réussi à le lancer en plein milieu de "MIRROR" !), ce qui permet de localiser immédiatement une erreur... Il est donc temps de décrire les trois parties qui composent ce programme, tout au long de trois chapitres, ca me parait logique. II - Le gestionnaire du Trackmos-DOS (sous-titre : le b..del mais reprogrammé) La première étape dans l'utilisation du TrackmoDOS est évidemment de créer une disquette dans un format approprié (si cela ne vous parait pas logique, essayez plutôt, je sais pas moi, DeluxePaint !) ; ce format s'appelle "T-DOS" et le gestionnaire ("handler") a pour but de le.. gerer, mais si mais si. Ledit gestionnaire est d'ailleurs le programme que vous affrontez lorsque vous lancez l'utilitaire : les deux autres parties, qui seront développées plus loin, sont installées par ce programme à l'endroit approprié sur les disquettes T-DOS et sont donc assemblées avec le gestionnaire dans un seul fichier, ne cherchez donc pas le TrackmoDOS ou le T-MON sur cette disquette... Bref, avant d'attaquer la description du programme, je tiens à prévenir mes fans (mon fan ?) que la version 3.0 du gestionnaire n'a absolument rien à voir avec les versions précedentes, ce qui est un peu normal vu que je l'ai reprogrammé entièrement ! C'est donc à une sorte de diskmaster futuriste que vous aurez désormais affaire, mais voyons pluto.. Votre perspicacité remarquera immédiatement (sauf si vous n'avez pas encore lancé le programme) que l'écran est divisé en gros en quatre parties. La première est la barre de titre et ne sert pas à grand chose d'autre qu'à afficher un texte... Notez cependant le carré tout en haut à droite qui sert à faire passer l'écran en arrière plan (le faire passer en avant-plan ne servirait pas à grand chose puisque l'écran n'est pas "draggable", autrement dit qu'il ne peut pas être déplacé verticalement à la souris, ceci parce que toutes mes tentatives de créer une barre de défilement personnelle ont débouché sur des gurus aussi nombreux que variés, je crois même en avoir créé de nouveaux... ceci dit si vous possédez le kickstart 2.0 ou plus, vous pouvez toujours scroller l'écran avec amiga gauche, le bouton gauche et la souris) ; en continuant la descente, on remarque deux filerequesters occupant à eux deux les trois quarts de l'écran. Celui de gauche sert à sélectionner le chemin d'accès pour les fichiers AmigaDOS (remarquez le gadget "volumes" qui sert à afficher la liste des lecteurs, volumes et assignations disponibles comme chemin de départ). Lorsue le directory AmigaDOS est apparu dans la fenètre, cliquer sur un sous-directory (affiché en blanc) l'ajoute au chemin d'accès et son contenu est affiché. Cliquer sur un fichier le sélectionne ou le déselectionne ; cette sélection sert aux commandes que nous verrons plus loin (je pense qu'il n'est pas utile d'expliquer l'utilité de la barre de défilement et des deux flèches qui l'accompagnent)... Le filerequester de droite est un peu différent. Il affiche le directory des disquettes au format T-DOS lorsqu'il y en a de disponibles. La fenètre comporte cinq gadgets facilement repérables, "df0:" à "df3:" et "AUTO". Les habitués de l'ancien gestionnaire doivent se douter de leur emploi mais il faut quand même que je le réexplique.. Cliquer sur "df0:", "df1:" "df2:" ou "df3:" verrouille la reconnaissance des disquettes T-DOS sur le lecteur choisi : lorsqu'une disquette T-DOS est introduite dans celui-ci, son contenu est affiché et la disquette est éditable par le programme. Les autres lecteurs sont ignorés. Le cinquième gadget, "auto" indique au programme de s'occuper de l'ensemble des lecteurs : introduire une disquette T-DOS dans n'importe lequel le sélectionne comme lecteur actif, affiche le contenu de la disquette et la rend éditable. Lorsque des fichiers T-DOS sont listés, cliquer dessus les active ou les désactive comme les fichiers AmigaDOS, le but est également de les indiquer aux commandes que nous allons voir sous peu : la quatrième et dernière zone de l'écran est en effet une série de 16 commandes en bas de l'écran qui remplace d'ailleurs une barre de menu qui a poussé au suicide plus d'un programmeur dans les versions précedentes. Trève de couillonnades, il est peut-être temps de décrire ces fonctions puisque je me suis cassé la nénette à les programmer : "COPY TO" permet de copier des fichiers dans le sens "AmigaDOS vers T-DOS". il faut donc disposer d'une disquette T-DOS (crée par la commande 'Format' expliquée un peu plus bas, ne paniquez pas) : tous les fichiers sélectionnés dans la fenètre AmigaDOS vont être transférés sur les pistes de la disquette T-DOS, dans le but donc de les recharger dans votre démo. Pour chaque fichier, le programme vous demande le nom que vous souhaitez utiliser pour l'identifier sur la disquette T-DOS ; dans ce format en effet, les noms sont limités à 8 caractères (on se croirait sur PC... argh !!) alors que l'AmigaDOS permet d'aller jusqu'à l'infini plus 1.. Bref pour chaque fichier un requester vous demandant le nouveau nom apparaitra. Valider le nom par "RETURN" ou cliquer sur le gadget "OK" du requester sauvegardera donc le fichier sous le nom voulu sur la disquette T-DOS, mais vous pouvez lors de tout requester interrompre le transfert en cliquant sur "CANCEL". "GETBACK" sert à repasser des fichiers du format T-DOS au format AmigaDOS, au cas par exemple où une pénurie de disquettes vierges vous obligerait à ne pas garder le fichier AmigaDOS original... Enfin bref, la commande fonctionne de façon assez évidente, chaque fichier sélectionné dans la fenètre T-DOS est retransféré au format AmigaDOS (sauvé dans le chemin indiqué dans le requester dudit format) ; notez cependant qu'aucun nom ne vous est demandé puisque l'AmigaDOS accepte très bien les noms T-DOS qui font 8 caractères maximum... "FORMAT" (enfin !) crée une disquette au format T-DOS, dans le but donc de transferer des fichiers avec la commande déja décrire "COPY TO" pour pouvoir les utiliser dans votre démo.. Un premier requester apparait vous demandant le nom de la disquette pour l'AmigaDOS. En effet, pour éviter tout conflit, le format T-DOS n'utilise pas la piste 40 lower side qui contient le root-block -ainsi, à y'être, que la bitmap et d'autres structures DOS marrantes- (à moins que vous désactiviez ceci dans les Preferences que nous verrons plus tard, mais ce n'est pas trop recommandé à moins que vous soyez à 5 KO près sur la disquette) ; l'AmigaDOS peut donc lire le nom de la disquette, histoire de. Le requester qui vous demande ce nom dispose d'un gadget "CANCEL" qui permet d'annuler le formattage. Mais si vous cliquez sur "OK" ou validez le nom par RETURN, un deuxième requester apparait vous demandant gentiment une "T-DOS diskmark". Il réclame en fait une marque de 4 octets (4 signes alphanumériques sont idéaux je pense) qui sert à reconnaitre la disquette du point de vue du TrackmoDOS lorsque votre production comporte plusieurs disquettes : chaque disquette possédant sa propre marque évitera ainsi à votre utilisateur de se planter.. Si vous ne nécessitez pas de marque particulière, entrez ce que vous voulez, vos initiales, le téléphone de votre copine (les 4 premiers numéros !)... Notez également que ce deuxième requester dispose encore d'un gadget "Cancel" (en fait TOUS les requesters de texte en comportent un, mais chut !) ce qui permet d'annuler encore le formatage. Si vous cliquez malgré tout sur "OK" ou encore une fois validez par RETURN (le fou !), la disquette est formattée en T-DOS ; les 80 pistes sont initialisées, puis le système TrackmoDOS est installé sur la piste 0 lower side de la disquette pour pouvoir démarrer tout seul comme un grand du boot-block, et enfin, le directory T-DOS est créé. La disquette est reconnue par le programme et vous pouvez donc installer immédiatement des fichiers dessus. Je viens de dire que le système TrackmoDOS démarre tout seul du boot, peut-être vous demandez vous comment il passe le contrôle à votre programme ? C'est simple : il suffit d'installer (avec "COPY TO") sur la disquette un fichier appelé "MAIN" (en majuscules !). Le TrackmoDOS l'appelera automatiquement, nous verrons d'ailleurs cela en détail dans le chapitre suivant. "KILLALL" efface instantanément le directory T-DOS, et efface donc instantanément tous les fichiers présents sur une disquette en ce format. C'est en fait la seule façon de virer des fichiers T-DOS, puisque ceux-ci sont écrits séquentiellement sur les pistes de la disquette (de toute façon vous devez être tout de même assez décidé quand aux fichiers à installer avec votre démo ?). Killall remet donc à zéro le répertoire, après un joli requester de sécurité, comme d'habitude. "PROTECT" comme son nom l'indique si vous speakez english, protège la disquette T-DOS en cours d'édition, contre toute lecture par le gestionnaire, et ceci A TOUT JAMAIS. Cela veut dire que si votre démo est fin prête, vous n'aurez peut-être pas envie que tout le monde récupère vos fichiers avec, justement, le programme qui vous a permi de les créer. Il suffit donc de faire "PROTECT" pour que le gestionnaire ne reconnaisse même plus la disquette comme étant au format T-DOS (mais évidemment votre démo sera toujours bootable, le TrackmoDOS, lui, continuera de lire vos fichiers, encore heureux !) "INFO" vous donne -sans blague- des informations sur la disquette T-DOS en cours d'édition.. nombre de fichiers, place totale occupée en octets et en secteurs, place libre en octets et en secteurs, pourcentage d'occupation.. de quoi faire jouir tous les amateurs de statistiques.. "VALID" est probablement la commande la plus débile du programme ! la demander produit en effet quelque chose de beaucoup plus marrant que 'protect' : cette commande installe un validateur spécial sur votre disquette T-DOS qui a pour effet comique de l'AUTOBOOTER même si vous êtes en plein milieu de DeluxePaint ! Pour essayer, créez donc une disquette T-DOS qui a un effet quelconque (comme vous saurez le faire après avoir lu l'ensemble de la documentation (j'espère !)), retirez-la et réinserez-là (pour qu'elle soit validée par l'AmigaDOS) et observez !! Le seul inconvénient -c'est pas ma faute- est que le kickstart 2.0 (ou 3.0, c'est le même ou presque) ne semble plus utiliser les "disk-validators" qui sont la clé de ce système : en français cela veut dire que cette commande n'a pas d'effet sur kick 2.0 ou 3.0 qui ignorent purement et simplement mon disk-validator ; mais seulement sur 1.2 ou 1.3, c'est comme ça ! Mais ceci dit protégez quand même vos productions avec un VALID suivi d'un PROTECT (sans ressortir la disquette entre les deux il n'y aura pas de problème)... C'est vraiment poilant ! "RENAME" permet ô surprise de renommer des fichiers T-DOS (pour l'AmigaDOS je pense que vous y arriverez tout seul !) : pour chaque fichier T-DOS sélectionné, un requester apparait pour vous demander le nouveau nom. Le valider par RETURN ou cliquer sur "OK" continue le renommage, cliquer sur "CANCEL" l'interrompt, je sais je me répête. "INSTMON" est l'abréviation d'"INSTALL T-MON" (pas assez de place !) ; cette commande permet donc d'installer le TrackmoDOS Monitor sur votre disquette T-DOS afin que celui-ci intervienne en cas de plantage ou d'appel de votre part, pendant votre démo. Le système TrackmoDOS charge en effet automatiquement le T-MON lorsque celui-ci est présent sur la disquette, comme expliqué plus mieux dans le chapitre suivant. "DISABLE" indique au système TrackmoDOS qu'il ne faut pas charger le T-MON même si celui-ci est présent sur la disquette. C'est en effet au cas où le T-MON serait présent sur la disquette finale de votre démo (pour des raisons de debuggage) et que vous voudriez le virer pour des raisons de place mémoire, de temps de chargement, ou ce que vous voulez. C'est donc la raison de vivre de DISABLE. "ENABLE" fait exactement le contraire de la commande précedente, au cas où vous auriez changé d'avis ! "SYSINFO" n'a pas de lien précis avec le format T-DOS, en fait. Cette commande, après une ou deux secondes de réflexion, vous affiche des informations complètes sur votre machine, essayez vous verrez bien ! "PREFS" affiche une fenètre qui vous permet d'orienter plusieurs fonctions du gestionnaire selon vos besoins. Cette fenètre affiche actuellement 6 choix et 3 requesters. Les 6 choix correspondent au 6 lignes de texte précédées d'un petit carré. Lorsque ce carré est vide, l'option est déselectionnée, et lorsqu'il est plein, l'option est, oui, séléctionnée, ouiii vous gagnez la télévision !! Les 6 choix actuels sont les suivants : "Protect track 40" : cette option active par défaut a été un peu expliquée avec la commande FORMAT qui est directement concernée : si cette option est active, lors du formatage la piste 40 de la disquette sera réservée pour éviter tout conflit entre AmigaDOS et T-DOS. Cela a également pour effet d'enlever environ 5 KO de précieux espace disquette. Si vous êtes un peu juste niveau place disquette ou si vous aimez les "checksum error 880" des kickstart 1.3 ou les rien-du- tout des kickstart 2.0, vous pouvez virer cette option qui je le rappelle n'a d'effet que lors du FORMATTAGE d'une nouvelle disquette. "Write TrackmoDOS code" : active par défaut également, cette option indique à la commande FORMAT si elle doit écrire le TrackmoDOS (le mini "système d'exploitation") sur la disquette lors du formattage en T-DOS... Ceci pour que la disquette 2 ou 3 de votre production ne soit pas bootable, par exemple. Il convient donc d'installer le TrackmoDOS sur la première disquette de votre projet uniquement... "Watch resetvectors" : bien que le but du programme ne soit pas de jouer à l'antivirus, le gestionnaire peut tout de même surveiller que personne ne touche aux vecteurs reset (capture et kickmachin) comme par exemple un virus malintentionné... Si les vecteurs reset sont touchés (sauf s'il vous positionnez le patch du kickstart 1.3 par "setpatch r" qui n'a évidemment rien à voir avec un virus même si certains programmes gueulent), une alerte apparait vous demandant si vous désirez effacer les vecteurs reset. Cliquer sur "Cancel" abandonne l'opération et déselectionne la surveillance des vecteurs pour que l'alerte ne revienne pas tout le temps. "OK" confirme donc quand à lui l'effacement des vecteurs. Si jamais celui-ci n'est pas possible (si le virus se régénère sous interruption) le gestionnaire le remarquera et vous proposera la solution du hardreset pour anéantir le virus.. Donc, "ok" ou "cancel", comme d'habitude.. "Display dirs before files" : indique si, lors de l'affichage du directory dans la fenètre AmigaDOS, les sous-directories doivent être groupés avant les fichiers ou apparaitre classés par ordre alphabétique en plein milieu des fichiers. Sélectionnez selon votre gout... "Custom iconify position" : permet de définir la position de la fenètre d'iconification : la commande ICONIFY -voir plus loin- libère tout ce qui est libérable et place le gestionnaire en état d'attente dans une fenètre sur le workbench. Cette option permet d'en définir la position : le workbench apparait en avant-plan avec une fenètre de la même taille que celle d'iconification ; déplacez là à l'endroit où vous voulez iconifier le programme et fermez-là (la fenètre bien sûr), la position sera mémorisée. "Close workbench screen" : si cette option est active, le programme ferme le workbench pour récupérer de la mémoire (s'il n'y arrive pas (fenètres présentes dessus !) l'option est désactivée), si elle est inactive le workbench est rouvert (si cela n'est pas possible en cas de réel manque de chipram l'option est réactivée !!) Les trois gadgets "Save" "Use" et "Cancel" fonctionnent comme sur les bonnes vieilles preferences du workbench 1.3 : "save" sauvegarde (dans le répertoire S:, d'ailleurs) les preferences selon votre choix (dont la position d'iconification...) et les valide; "use" valide les préferences sans les sauvegarder et "cancel" efface votre modification des preferences et remet donc l'ancienne configuration. "ICONIFY" permet donc d'iconifier le programme comme tout utilitaire qui se respecte. Seule une petite fenètre sur le WorkBench subsiste. Il suffit de la fermer (toujours la fenètre) (ou de cliquer sur le bouton droit lorsqu'elle est active) pour que le programme reprenne ses aises. "ABOUT" affiche le genre de message qu'amène généralement cette commande, un appui sur "RESUME" le vire. "QUIT" permet of course de quitter (quoi ?? ah, c'est pour programmer sous TrackmoDOS lui-même, je préfère ça) après un requester de sécurité... A propos de requesters, notez que tous les requesters supportent les raccourcis claviers "Amiga V" (pour OK) et "Amiga B" (pour CANCEL). Toujours à propos de requesters, il faut peut-être que je vous prévienne, les requètes système "system request" du genre "please insert volume gnagnagna in any drive" ont un look nouveau lorsque mon programme est actif (il faut reconnaitre qu'un certain programmeur appelé FireBlade m'y a un peu poussé), essayez c'est pas triste... Puisqu'on parle de Fireblade, vous êtes peut-être étonnifié de ne pas retrouver son programme couplé au mien comme d'habitude.. C'est tout simplement que son TDM (dernière version en date, 2.6 je crois) ne supporte pas la sélection multiple (bouuuuh ! uuuuh !), autrement dit il disjoncte si je lui envoie plusieurs fichiers à la fois... Maiiis je ne doute pas que cet étrange programmeur finira par résoudre le problème juste pour m'obliger à sortir une nouvelle version ; m'enfin... Bon, bref, il vous est donc maintenant facile de créer des disquette T-DOS avec toutes les données nécessaires à votre démo, il ne vous reste plus qu'à recharger ledites données quand il le faut, simplement mais puissamment (pas de rires please) comme nous allons le voir en explorant, le, le ... III - Le TrackmoDOS, le vrai, l'unique Pour gérer efficacement le format T-DOS, il y avait plusieurs moyens, comme par exemple celui de vous fournir en source la routine de trackload s'occupant de charger les fichiers, mais c'était toujours trop fatiguant pour le feignant que je suis parfois. N'écoutant que mon courage j'ai donc décidé de programmer carrément un 'environnement' (pour ne pas employer le terme de 'système d'exploitation' qui ferait quand même prétentieux ici) pour vos démos qui ainsi sont libérées d'un certain poids comme nous allons le voir. Le programme du Trackmo-DOS est donc installé par son petit copain le gestionnaire sur votre disquette, sur la piste 0, lower side très exactement. Le DOS démarre donc le bootblock programmé par mes soins, qui après avoir chargé l'integralité du TrackmoDOS, se renseigne -en utilisant les libraries système, pour la compatibilité- sur la configuration mémoire, la liste des drives connectés, le type de processeur, de coprocesseur, d'agnus et de denise, la version de la ROM et stocke tout cela dans une structure qui vous est accessible (nous verrons plus loin comment). Puis le programme 'tue' l'AmigaDOS (passage en superviseur, remise à zéro des registres hard etc.), se recopie à l'adresse $00000000 (donc totale gestion du 68000 par TrackmoDOS). Il initialise alors son gestionnaire mémoire, puis essaie de charger le debugger ("T-Mon") : s'il est présent, il l'initialise (les exceptions 68000 sont dirigées sur lui) sinon il n'en fait pas une maladie et en cas d'exception, un reset sera effectué et un guru standard sera affiché avec le numéro d'exception (comme d'habitude) et l'adresse du plantage (au lieu de l'adresse de la tâche comme normalement...). Après cette init éventuelle du T-Mon, le TrackmoDOS charge le fichier T-DOS appelé 'MAIN'. S'il n'existe pas, le programme fait un reset (avec une super couleur violette pour signaler l'erreur) ; sinon il lui passe la main. A cet endroit, toute dma et interruptions sont interdites ; le programme 'MAIN' aura à mettre lui-même la dma et les interruptions dont il a besoin. Ce fichier 'MAIN' est comme dêja expliqué le programme principal de votre démo, ce qui vous permet donc de démarrer la démo du boot sans lever le petit doigt, comme annoncé fièrement dans l'introduction. Ce programme 'MAIN' doit être un fichier exécutable normal (pas d'ORG !!!), pour les raisons que nous allons voir. Trackmo-DOS a beau être un petit système d'exploitation, il tourne tout de même sur un Amiga. Et sur un Amiga, on est tellement habitué à se faire gérer la mémoire qu'on ne peut pas s'en passer. Et donc, Trackmo-DOS gère la mémoire de la même manière qu'AllocMem et FreeMem du système d'exploitation, vous demandez une certaine taille (et un certain type de mémoire (CHIP/FAST/LES DEUX) si vous voulez), Trackmo-DOS alloue de la mémoire et vous fournit l'adresse ; et quand vous en avez fini, vous libérez la mémoire, point. Ca permet de ne pas se casser la tête à savoir si l'Amiga dispose d'extensions mémoire ou pas, Trackmo-DOS s'occupe de tout cela pour vous. Ce qui est découle est que les programmes et données sont chargés dans de la mémoire allouée dynamiquement, autrement dit, il n'est pas recommandé de charger des données ou des programmes à une adresse fixe avec Trackmo-DOS, bien que celui-ci vous laisse le choix... 'MAIN' est donc chargé par le Trackmo-DOS avec une routine qui a un effet similaire au 'LoadSeg' de l'AmigaDOS, c'est pour cela que ce fichier 'MAIN' doit être un programme exécutable (même si cela provoquerait un crash de le lancer par l'AmigaDOS vu ce qu'il va faire...). Cette routine 'simulatrice de LoadSeg' est bien entendu accessible à votre démo, ca permet donc de fragmenter le programme et de le charger au fur et à mesure. Cette souplesse de gestion de la mémoire rappelle un peu l'Amigados et le système de l'Amiga, c'est cela que j'appelais 'utiliser les avantages du DOS' (gestion souple de la mémoire) 'sans ses inconvénients' (lenteur etc.). Je vous encourage donc à programmer vos démos dans cette optique d'allocation/libération de mémoire, sans utiliser des programmes assemblés à des adresses absolues qui pourraient corrompre la gestion de la mémoire par le Trackmo-DOS. De toute façon, le Trackmo-DOS offre des routines permettant de charger des données ou des programmes en allouent de la mémoire de facon totalement automatique, ce qui permet d'utiliser ce système de mémoire dynamique sans s'emm... ; cela offre également le grand avantage d'être compatible avec toutes les extensions mémoire passées et futures car Trackmo-DOS récupère au démarrage la liste mémoire d'exec.library, ce qui veut dire que si la machine dispose par exemple de 2 MO de chipram comme les nouveaux A1200 ou A4000, ils sont utilisables par votre démo. Vous pouvez donc vous targuer d'être '500+' ou '1200' 'compatible' sans grand effort -- d'autant plus que la routine de trackload utilisée est programmée de façon à fonctionner même avec un 68040 ! Trackmo-DOS possède également quelques fonctions sympa pour décompacter les fichiers DATA de PowerPacker, et cela de façon quasi-transparente, vous pouvez donc compacter toutes vos données et les récupérer sans effort (je suis en train d'étudier un compacteur plus puissant, ce sera pour la prochaine version...) Toute l'histoire est donc d'accéder à ces fonctions dont je parle depuis le début de ce chapitre. Rassurez-vous, encore une fois, c'est SIMPLE : à l'adresse $00000004, l'adresse 4 quoi, se trouve un pointeur, non plus sur exec.library puisqu'elle est morte et enterrée, mais sur une structure baptisée 'tdos.toolbox' qui permet d'appeler les routines précitées et de récupérer quelques renseignements interessants. Un fichier 'include' (tdos.i) est fourni avec ce package, qui liste cette structure en détail et donne tous les offsets de fonctions TrackmoDOS, mais pour les mordus du Seka et pour les besoins de la doc, voyons un peu cette tdos.toolbox : - les fonctions (la structure négative) : -4 size = FSize (filename)(a0) -8 ok = Load (filename,address)(a0) -12 adr = LoadAlloc (filename,memtype)(a0,d0) -16 adr = LoadSeg (filename,memtype)(a0,d0) -20 adr = MemAlloc (size,memtype)(d0,d1) -24 MemFree (adr,size)(a1,d0) -28 PPDepack (ppfile,endppfile,dest)(a0,a1,a2) -32 adr = PPLoad (filename,memtype)(a0,d0) -36 PPFree (adr)(a0) -40 ok = CheckMark ()() -44 WaitDisk (drive)(d0) -48 size = MemAvail (memtype)(d0) Le chiffre à gauche de chaque fonction est bien entendu l'offset à utiliser (par rapport à l'adresse base stockée en $4) pour appeler ladite fonction. 'FSize' permet de connaitre la taille d'un fichier. On doit lui passer dans a0 l'adresse du nom du fichier T-DOS à examiner. En sortie, d0 contient la taille du fichier demandé, ou 0 si celui-ci n'existe pas (ou si read/write error en lisant le directory). 'Load' sert à charger un fichier à une adresse spéciale en mémoire. Vous pouvez par exemple, en combinaison avec FSize et les fonctions d'allocation mémoire expliquées plus loin, réserver de la mémoire pour le fichier, en connaissant sa taille avec FSize, et le charger avec Load... Mais quoi que vous vouliez en faire, la fonction attend dans a0 l'adresse du nom du fichier T-DOS à charger, en dans a1 l'adresse de chargement. En retour, d0 contient 0 si tout s'est bien passé, ou -1 si une erreur de chargement a eu lieu (fichier inexistant, read/write error sur le directory ou sur le fichier lui-même) 'Loadalloc' permet d'automatiser le processus de réservation de mémoire pour le fichier et chargement de celui-ci: c'est cela que j'appelais 'utiliser le système de mémoire dynamique sans effort'.... La fonction a besoin dans a0 de l'adresse du nom du fichier à charger, et dans d0 du type de mémoire à réserver. Les types reconnus par Loadalloc (et par la routine d'allocation mémoire qui est appelée par LoadAlloc de façon interne !) sont quasiment les mêmes qu'AllocMem() : MEMF_CHIP (égal à 2) qui force donc ici le chargement du fichier en chipram, MEMF_FAST (égal à 4) qui oblige le fichier à se charger en fastram (cet attribut sera je pense rarement utilisé, en effet demander obligatoirement de la fastram nécessite une bonne raison !), et MEMF_ANY (égal à 0) qui indique que le type de mémoire n'a pas d'importance, si il reste de la fastram, on en réserve, sinon on alloue de la chip. La fonction retourne dans d0, l'adresse du fichier ainsi chargé ; d0=0 si un erreur disquette s'est produite; d0=-1 si il n'y avait plus assez de mémoire pour charger le fichier. Si vous avez besoin de la longueur du fichier, qui est également la taille de la mémoire allouée (il vous faudra cette longueur pour libérer ladite mémoire !), inutile de faire un 'FSize' : la longueur du fichier chargé par LoadAlloc est disponible dans un mot long de la structure tdos.toolbox baptisé 'lastlength' qui sera étudié plus bas : ce mot long contient toujours la taille du dernier fichier chargé, après un LoadAlloc, mais aussi d'autres fonctions que nous allons aborder, comme LoadSeg. Le processus normal de chargement de fichiers dans votre trackmo est donc, chargement par LoadAlloc avec récupération de la longueur stockée dans LastLength, utilisation des données et libération de la mémoire en donnant l'adresse renvoyée par LoadAlloc et la longueur récupérée (comme on le verra dans l'explication des fonctions mémoire). 'LoadSeg' agit comme la fonction du même nom de l'AmigaDOS. Elle permet de charger un programme à une adresse non fixe, même si celui-ci n'est pas écrit en code dit 'relogeable', grâce à une table de relogement stockée avec le programme, le tout était baptisé 'fichier exécutable'. TrackmoDOS est capable de charger de tels fichiers, c'est même la méthode la plus sûre pour fragmenter le programme de sa démo et le charger au fur et à mesure (faire un programme principal ("MAIN"...) qui chargerait et appelerait les différentes parties du code). LoadSeg attend dans a0 l'adresse du nom du fichier à charger, et dans d0 le type de mémoire à allouer, de la même manière que LoadAlloc (attention : LoadSeg n'agit pas tout à fait comme l'AmigaDOS et ignore les flags de chargement en chip etc. contenus dans le fichier. De plus elle alloue la mémoire nécessaire au chargement en un seul bloc et non pas hunk par hunk - ce n'est que la première version... - ; tous les hunks se retrouveront donc à la suite dans le même type de mémoire (chip ou fast). C'est pour cela que la mémoire réservée par LoadSeg sera libérée de la même manière que pour LoadAlloc - le champ LastLength contient la place que prend le fichier en mémoire après relogement ("déhunkage"), et non pas sa taille originale sur la disquette ; LastLength indique donc la taille mémoire à libérer). Bon, bref, en sortie, d0 indique l'adresse du fichier (comme LoadAlloc, encore une fois...) ; d0=0 si erreur disk, d0=-1 si erreur mémoire, et d0=-2 (le petit nouveau) si le fichier à charger n'était pas "éxécutable". -- Le programme 'MAIN' est d'ailleurs chargé par le TrackmoDOS avec cette fonction. Ce qui est très important et que vous devez retenir, c'est que TrackmoDOS charge toujours MAIN en chipram, ce qui permet d'utiliser copperlistes et autres directement dans le programme principal. 'MemAlloc' agit EXACTEMENT comme AllocMem d'exec.library. Cette fonction (qui est appelée de manière interne par à peu près toutes les routines évoquées au dessus) sert bien entendu à allouer de la mémoire dynamiquement, c'est la base de la gestion de la mémoire par TrackmoDOS. Elle attend, comme sa grande soeur AllocMem, dans d0 la taille mémoire à réserver, et dans d1 le type de cette mémoire (voir LoadAlloc). En retour, d0 contient l'adresse de la mémoire réservée, ou d0=0 si il n'y a plus de mémoire du type demandé (ou plus de mémoire tout court si vous n'avez rien demandé de spécial et donc donné MEMF_ANY). 'MemFree' est l'indispensable complément de MemAlloc, et a pour but vous vous en doutiez à libérer de la mémoire (si vous ne vous en doutiez pas, reprenez du début !), celle allouée par MemAlloc mais aussi par LoadAlloc et LoadSeg. La fonction demande dans a1 l'adresse de la mémoire à libérer, et dans d0 la taille de la mémoire en question. MemFree ne donne rien en retour (si la mémoire à libérer n'était pas allouée, le système plante ('bogus exception failure',guru #81000009), c'est tout !) 'PPDepack' est une fonction privée et non documentable. 'PPLoad' sert à charger un fichier PowerPacker et à le décompacter sans que vous ne faisiez plus d'éfforts qu'avec un LoadAlloc normal. Elle attend en entrée les mêmes paramètres que LoadAlloc, à savoir dans a0 l'adresse du nom du fichier à charger, et dans d0 le type de mémoire à réserver pour mettre le fichier décompacté. En sortie, le fichier est chargé et décompacté bien entendu, et d0 contient l'adresse du début du fichier décompressé ; d0=0 si erreur disk ; ou d0=-1 si erreur mémoire. Cette fonction permet donc de récupérer les fichiers data de PowerPacker de manière quasi transparente, ce qui n'est pas négligeable si les données sont assez volumineuses mais doivent tenir sur un disk... 'PPFree' sert à libérer la mémoire occupée par un fichier chargé par PPLoad. Il faut utiliser cette routine et non pas MemFree car la mémoire est allouée de façon assez particulière (pour permettre de limiter au maximum la taille mémoire à utiliser pour décompacter le fichier : seulement 8 octets de plus que la taille du fichier décompressé). Bref, PPFree a besoin dans a0 de l'adresse renvoyée par PPLoad, et se charge du processus de libération pour vous. La commande ne renvoie rien, la mémoire est juste libéreé (ou plantage si l'adresse fournie ne correpond pas à une adresse renvoyée par PPLoad !). 'WaitDisk' attend l'insertion d'une disquette dans un lecteur ; ceci est particulièrement utile pour les démos en plusieurs disquettes qui peuvent ainsi continuer à se charger sur un drive externe, ca fait un bon effet (On verra sous peu comment savoir quels drives sont rattachés à l'Amiga.). La commande attend dans d0 le numéro du drive avec lequel on va attendre l'insertion d'une disquette. WaitDisk attend en fait qu'une disquette au format T-DOS et ne présentant pas de problèmes de lecture soit introduite (il boucle tant que ces conditions ne sont pas remplies !). Lorsqu'un disk correct a été inséré, WaitDisk bascule toutes les routines de chargement sur le lecteur demandé au départ (traduction, tout LoadMachin chargera désormais à partir du drive demandé !), et finit en mémorisant le directory (au format T-DOS) de la disquette introduite. En effet, pour gagner du temps au chargement, TrackmoDOS ne relit pas constamment le directory mais le garde en mémoire. Nous verrons dans un chapitre postérieur (consacré au programmeurs tordus !) comment est consitué ce directory, mais ce n'est pas le propos ici, et de toute façon cela ne sera pas nécessaire au commun des mortels. -- Remarque : si le drive demandé est le même que le drive qui était utilisé jusqu'à l'appel de WaitDisk, la commande attendra que l'utilisateur retire la disquette puis en insère une autre. Par contre si l'attente doit se faire sur un lecteur différent de celui utilisé jusque là, et qu'une disquette valide est dêja présente dedans, WaitDisk l'examinera, et si elle valide, il rendra immédiatement la main, ce qui permet donc à l'utilisateur d'insérer la deuxième disquette de votre démo dans son drive externe au démarrage avant que vous ne la lui demandiez, alors que le pauvre possesseur d'un seul drive aura bien entendu à changer de disquette... 'Checkmark' est un complément à la commande précédente ; cette fonction permet de tester si une certaine marque est présente sur le disk, et donc de vérifier que l'utilisateur ait inséré la bonne disquette (il peut avoir remis la disquette 1, WaitDisk ne dira rien !) ; CheckMark permet donc d'éviter les conséquences d'un chargement sur une disquette inconnue.. La fonction n'attend rien en entrée. Elle lit le premier secteur de la disquette (le boot donc), place la valeur contenue en boot+8 dans d0 et sort. Sur les disquettes AmigaDOS, en 'boot+8' se trouve la valeur 880 ($370) qui sert à indiquer la position du rootblock. Comme on s'en balance pour le format T-DOS, à cet endroit se trouve la marque de 4 octets demandée par la commande "Format" du gestionnaire qui est n'importe quoi qui tient sur 4 octets (du genre 'DSK2' pour disque 2...) qui servira ensuite à identifier la disquette. Il vous suffira donc de faire un CheckMark et de comparer la marque obtenue dans d0 avec la marque que vous attendez pour savoir si la bonne disquette a été introduite (si les deux marques sont différentes, il convient de retourner sur WaitDisk (le mieux est de faire une boucle infinie jusqu'à ce que l'utilisateur mette la bonne disquette) ; comme le lecteur demandé pour WaitDisk sera maintenant le même que le lecteur courant, WaitDisk attendra donc un changement de disquette, donc tout va bien... 'MemAvail' permet de connaitre à tout moment la quantité de mémoire disponible d'un type donné ..ou pas. La fonction attend dans d0 le type de mémoire à examiner (comme MemAlloc, c'est à dire MEMF_CHIP, MEMF_FAST ou MEMF_ANY), et retourne dans d0 la quantité de mémoire disponible du type demandé (ou la quantité de mémoire disponible totale si MEMF_ANY a été donné). Cette fonction fonctionne de façon similaire à AvailMem() d'exec.library, d'ailleurs. L'étude des différentes fonctions est maintenant, terminées, passons donc maintenant aux différentes informations que TrackmoDOS met à votre disposition, autrement dit... - la structure positive : offset nom taille --------------------------------- 0 tb_sysmark mot long 4 tb_df0 octet 5 tb_df1 octet 6 tb_df2 octet 7 tb_df3 octet 8 tb_activedrive octet 9 tb_pad octet 10 tb_lastlength mot long 14 tb_diskerror mot 16 tb_totalchip mot long 20 tb_totalfast mot long 24 tb_agnustype octet 25 tb_denisetype octet 26 tb_displaytype octet 27 tb_proctype octet 28 tb_coproctype octet 29 tb_kickver octet 'tb_sysmark' est une marque qui identifie la structure tdos.toolbox. Il s'agit des quatres lettres 'tdos' en minuscule, ce qui constitue donc un mot long. Cette marque n'a donc pas de fonction particulière autre que signaler la présence de la tdos.toolbox (l'adresse contenue en $4 doit toujours pointer sur cette marque, sinon il y a un gros problème !!!)? 'tb_df0' à 'tb_df3' sont des flags qui indiquent les lecteurs connectés. Chacun de ces 4 champs est égal à $FF si le lecteur qui leur correspond est disponible, ou 0 si le lecteur en question n'est pas connecté. Evidemment, tb_df0 sera toujours égal à $FF, puisque df0: à 100% de chances d'être connécté ! En résumé, pour tester la présence d'un lecteur supplémentaire (pour ensuite faire un WaitDisk et charger la deuxième disquette de votre démo à partir de celui-ci, par exemple...), il suffit de tester le flag qui lui correspond (avec une instruction TST, la commande de branchement BEQ sautera si le lecteur concerné n'existe pas). 'tb_activedrive' indique le lecteur courant. Cela n'a pas une grande utilité pour vous, mais il fallait bien que le TrackmoDOS le stocke quelque part ! 'tb_pad' est un octet servant à réaligner le mot long qui suit sur une adresse paire, il n'a pas de fonction autre que celle-ci et est normalement égal à 0. Il se pourrait cependant que de futures versions de TrackmoDOS s'en servent pour des informations supplémentaires, ne l'utilisez donc pas pour stocker quelque chose. 'tb_lastlength' est le fameux champ LastLength dont on parle depuis le début de ce chapitre, c'est donc ici que vous pourrez récupérer la longueur du dernier fichier chargé... 'tb_diskerror' est un mot contient l'explication de la dernière erreur disquette. Autrement dit, si une commande de chargement a renvoyé un -1 ("erreur disk"), ce champ permet d'en savoir plus, afin par exemple d'afficher un message à l'utilisateur (peut-être pas pour une démo, mais pour un music disk ou un diskmag, ca fait classe !). Bref, actuellement, les quatre raisons pour lesquelles une erreur disquette peut se produire sont DE_READERROR (= $0008), c'est à dire une erreur 'hard' sur la disquette (piste illisible) ; DE_NODISK (=$0010), qui se produit quand il n'y a pas de disquette dans le lecteur à partir duquel on charge (celle-ci a pu être retirée !) ; DE_NOTDOS (=$0018), qui indique que la disquette sur laquelle vous demandez une lecture n'est pas au format T-DOS (l'utilisateur a pu changer de disquette...) ; et DE_FILENOTFOUND (=$0020) qui indique que le fichier n'a pas pu être lu (ou examiné dans le cas de FSize) tout connement parce qu'il n'a pas été trouvé (nom inconnu). Ceci conclut avec notre étude de la structure positive. 'tb_totalchip' est un mot long qui contient la quantité de mémoire CHIP disponible au démarrage de la machine (en octets). Cela vous permet par exemple de tester si la machine dispose d'une extension de chip... 'tb_totalfast' est un mot long qui contient quand à lui la quantité de mémoire FAST (oh, vraiment ?) au démarrage de la machine (en octets aussi). Si la machine dispose de 5 MO de fastram, vous le saurez... Ne croyez pas que ces deux champs font double emploi avec MemAvail, ils indiquent en permanence quelle quantités mémoires étaient disponibles avant la moindre allocation. 'tb_agnustype' vous indique quel type d'agnus possède la machine sur laquelle vous lancez la démo (si jamais vous necessitez 1 MO de chip ou je ne sais pas trop quoi, c'est là qu'il faut tester !) : ce champ peut contenir TB_NORMALAGNUS (=$10) qui identifie le vieil agnus (512K chip), TB_FATAGNUS (=$11) qui identifie le fat agnus (1MO chip), et TB_SUPFATAGNUS (=$12) qui identifie le superfatagnus (2MO chipram). 'tb_denisetype' dit quel type de denise possède la machine (si vous avez une part de votre démo qui tourne en mode Productivity et que vous necessitez superdenise...) : deux valeurs sont possibles actuellement, TB_NORMALDENISE (=$20) qui identifie la bonne vieille Denise, et TB_SUPERDENISE (=$21) qui identifie la nouvelle SuperDenise de l'ECS (ou AGA). 'tb_displaytype' indique quel type d'affichage possède la machine (à tester pour les démos PAL (toutes) !) : deux valeurs sont possibles, TB_DISPLAYNTSC (=0) qui indique un affichage NTSC américain et TB_DISPLAYPAL (=$FF) qui identifie un affichage PAL européen (yeahh!). 'tb_proctype' indique quel type de processeur possède la machine. Les valeurs possibles vont de TB_MC68000 (0) à TB_MC68040 (4). 'tb_coproctype' indique si un coprocesseur mathématique est connecté à la machine ou non. On peut trouver ici TB_NOCOPROC (=0) si aucun coprocesseur n'est présent, ou TB_COPROC (=$FF) si un coprocesseur mathématique (MC68881 ou MC68882...) est présent. 'tb_kickver' contient le numéro de version du kickstart (de la rom donc), ce à titre purement informatif puisque le système est mort.. Vous trouverez donc le numéro de VERSION et non pas de release, ce qui veut dire que vous obtiendrez : 33 pour la rom 1.2, 34 pour la rom 1.3, 36 pour la rom 2.0 (la vieille, celle des premiers A3000), 37 pour la rom 2.04 actuelle (ce qu'on appelle le 2.0, disponible sur tous les 500+ et 600 par exemple), et 39 pour la rom 3.0 (des A1200 et A4000). Des valeurs supérieures apparaitront très certainement dans quelques temps, vu qu'on parle beaucoup du Kickstart 4.0 du côté de chez West Chester (Commodore USA...) Je le rappelle, tous les offsets de fonction, les champs de la structure positive et certains flags à utiliser pour certaines fonctions (comme par exemple MEMF_CHIP, TB_FATAGNUS...) sont définis dans le fichier include "tdos.i", utilisable sur AsmOne ou Devpac II/III (pour Sekabeurk vous n'avez qu'à l'insérer dans votre source !). Il convient de placer ce fichier tdos.i dans le répertoire 'include/misc' de votre disquette d'includes assembleur. - Exemples Pour clarifier (si on peut dire) un peut tout ce b..., voici un ou deux exemples de morceaux de 'programme principal' démontrant quelques fonctions du TrackmoDOS (ce ne sont que des exemples, inutile de les essayer !) : Premier exemple, chargeons une musique avec LoadAlloc, histoire de rigoler un peu (je suppose évidemment que vous disposez des routines musicales adéquates...) : ; "opt c-" recommandé si Devpac incdir "include:" include "misc/tdos.i" ; on inclut les offsets, etc. du TrackmoDOS start lea music_name(pc),a0 ; on pointe sur le nom du fichier à charger moveq #MEMF_CHIP,d0 ; la musique se charge en chip !!! CALLTDOS LoadAlloc ; la macro CALLTDOS sert à appeler une fonction ; du TrackmoDOS, ici 'LoadAlloc' tst.l d0 beq.s disk_error ; d0=0 -> erreur disk bmi.s mem_error ; d0=-1 -> erreur mémoire move.l d0,musicadr ; étant donné que 'MAIN' est un programme ; exécutable (auto-relogement) vous pouvez ; parfaitement faire cela... ; donc ici on stocke l'adresse de la zikemu.. move.l tb_lastlength(a6),msize ; après un CALLTDOS l'adresse de base de ; tdos.toolbox se trouve toujours dans a6 ! bsr mt_init ; c'est comme ça d'habitude que s'appelle ; la routine d'initialisation d'une musique ; Protracker... ... ; suite du programme... bsr mt_end ; on arrête la musique (par exemple) move.l musicadr(pc),a1 ; on récupère l'adresse de la musique move.l msize(pc),d0 ; et sa longueur CALLTDOS MemFree ; on libère sa mémoire... ... music_name dc.b 'MOD.FUN',0 ; (nom totalement bidon !) ; un nom de fichier doit se terminer par un ; zéro, comme avec l'AmigaDOS. Mais n'oubliez ; pas, TrackmoDOS accepte 8 caractères maxi ! ; (le zéro ne compte pas dans les 8, bien ; sûr !) even musicadr dc.l 0 msize dc.l 0 ... Simple et clair, non ? (non, pas trop, je sais... Mais c'est au moins aussi simple qu'avec l'AmigaDOS, alors ...). Notre deuxième exemple portera sur le couple WaitDisk / CheckMark qui a pu (qui a du ?) vous laisser perplexe... On suppose que la disquette à attendre possède la marque 'DSK2' positionnée lors du formattage ; on suppose aussi que nous sommes en plein milieu du programme : ... move.l 4.w,a6 ; on prend l'adresse de base de tdos.toolbox moveq #1,d0 tst.b tb_df1(a6) ; df1: connecté ? bne.s wait_disk2 ; oui, on utilise df1: moveq #2,d0 tst.b tb_df2(a6) ; df2: connecté ? bne.s wait_disk2 ; oui, on utilise df2: moveq #3,d0 tst.b tb_df3(a6) ; df3: connecté ? bne.s wait_disk2 ; oui, on utilise df3: moveq #0,d0 ; pas de drive externe, on se sert de df0: ! wait_disk2 CALLTDOS WaitDisk ; d0 contient dêja le numéro du drive, ; (voir ci-dessus !) -> on attend une ; disquette dans le drive voulu... CALLTDOS CheckMark ; on lit la marque contenue sur le boot cmp.l #'DSK2',d0 ; est-ce ce qu'on attend ? bne.s wait_disk2 ; si ce n'est pas le cas, on attend encore... lea filename(pc),a0 ; sinon on peut maintenant charger sur la moveq #MEMF_PUBLIC,d0 ; disquette fraichement insérée ! CALLTDOS LoadAlloc ; (ici chargement totalement bidon mais ; qui démontre qu'il n'y a rien à faire de ; spécial après un WaitDisk, la disquette ; insérée est automatiquement lue !) ... Cet exemple termine notre étude du TrackmoDOS, j'espère qu'il ne vous parait pas TROP compliqué et que vous pourrez ainsi programmer vos Trackmos beaucoup plus simplement (imaginez le nombre d'heures que j'ai passé à écrire ces fonctions !) ; donc, fin de ce chapitre, nous allons maintenant nous attaquer à quelque chose de plus marrant... IV - Le TrackmoDOS Monitor, le T-Mon quoi ! Tout coder fait des erreurs en programmant, c'est normal, errare humanum est (ou quelque chose comme ça). Cependant, enlever ces erreurs n'est pas toujours simple ; on ne sait pas toujours d'où un plantage vient, etc., surtout que dans le cas d'une démo, le plantage peut survenir en plein milieu, et le système étant .. mort .., vous n'avez aucun moyen de déterminer la source de l'erreur. C'est en prenant conscience de cela (et pour vous simplifier encore plus la vie, si c'est encore possible !) que j'ai écrit le T-Mon, un moniteur (même un petit debugger) conçu pour être utilisé avec le TrackmoDOS, qui n'utilise donc absolument aucune fonction du système AmigaDOS. Lorsqu'un plantage qui provoque une exception 68000, un guru quoi (erreur d'adresse, instruction illégale, division par zéro, etc.) survient, T-Mon est appelé, vous pouvez alors, par exemple, désassembler à partir du PC (l'adresse où ca à planté quoi), repérer l'erreur et corriger (T-Mon possède un assembleur intégré)... Vous pouvez même continuer votre démo après correction, ou même la tracer instruction par instruction, cela ne pose aucun problème. Le T-Mon peut même être appelé par votre programme même s'il n'y a pas eu de plantage, pour une raison qui vous appartient.. Concrètement, le T-Mon est installé par le TrackmoDOS en mémoire à une adresse qui dépend de la mémoire disponible. Cette adresse ne vous est pas communiquée car vous n'en avez pas besoin : T-Mon intercepte les 'line-f' (guru 0000000B.XXXXXXXX) du 68000 de façon spéciale - ces line-f servent à l'appeler quand il n'y a pas eu d'exception. Un "line-f #$000" (ou dc.w $F000 si votre assembleur ne supporte pas directement l'instruction line-f) appelera le T-Mon ; en sortant du T-Mon l'exécution de votre démo continuera après le line-f, le plus naturellement du monde, en restaurant le contexte (dma, interruptions etc.) dans lequel se trouvait votre démo. Cependant, il y a quelque chose qu'il faut fournir au T-Mon car il ne peut pas la deviner : c'est l'adresse de la copper-list qui doit être mise en sortant du moniteur ; l'idéal est d'informer T-Mon en tout début de programme, comme ça si un plantage survient et que vous devez revenir pour une raison ou pour une autre dans votre démo, la bonne copper-list sera utilisée. Pour préciser cette l'adresse de cette liste copper au moniteur, il suffit de faire un line-f #$001 (dc.w $F001, surtout n'ayez pas peur de le mettre au beau milieu de votre programme !) avec a0 pointant sur votre copperliste, ce n'est pas plus difficile que ça. Donc, exemple de programme principal : incdir "include:" include "misc/tdos.i" start lea my_coplist(pc),a0 ; on pointe sur la copperlist line_f #1 ; et on l'indique au T-Mon ... ; on fait ce que l'on veut line_f #0 ; force l'appel du T-Mon ... ; le programme continue... Après un line_f #0, l'écran fatidique du T-MON version 2.0 (sisi, c'est la toute nouvelle version ! Le TrackmoDOS 2.0 disposait de la version 1.0 du moniteur, c'est très logique) apparait avec un bref texte de copyright... Le prompt ">" se pointe avec son curseur : le T-Mon attend vos ordres. Je ne compte pas détailler ici chaque fonction du moniteur, elles sont assez classiques (assemblage, désassemblage, copie de mémoire, dump etc. - ce qui fait l'originalité du T-Mon c'est d'être prévu pour le TrackmoDOS !), mais je voudrais plutôt insister sur certains points importants : Tout d'abord, vous remarquerez que l'édition de la ligne de commande a été grandement améliorée, elle est comparable au Shell de l'AmigaDOS maintenant (essayez vous verrez bien !). La liste complète des fonctions est accessible avec les touches F1 et F2 (F3 donne un petit message de copyright). T-Mon possède permet de poser des calculs dans les arguments que l'on fournit aux différentes fonctions. Il reconnait les trois bases de calcul classiques -bien que rarement reconnues- (décimale : le nombre seul ; hexadécimale : le nombre précédé d'un '$' ; et binaire : le nombre précédé d'un '%'), ainsi que les opérations d'addition "+", de soustraction "-", de multiplication "*" et de division "/". Il est donc parfaitement correct d'écrire "A $50000+16" pour assembler en $50010 ($50000 plus 16, donc...). On sort de la commande d'assemblage avec RETURN tout seul. T-Mon possède une fonction (J)ump (un JSR quoi) qui permet d'exécuter une routine 68000. Mais étant prévu pour debugger votre démo, lorsque vous faites un Jump, T-Mon remet le contexte (dma, interruptions, etc.) comme il était avant son appel, exécute la routine demandée puis remet son propre contexte. Donc rappelez vous bien de cela lorsque vous exécuterez une routine avec Jump. Le moniteur possède également une fonction (J)ump no conte(X)t qui permet d'exécuter une routine n'utilisant pas de dma ou interruptions spéciales, en superviseur, dans le même contexte que le moniteur ; ca peut je crois être utile ! Je crois ne pas avoir assez parlé des commandes "ECHO ON" et "ECHO OFF" dans les précédentes versions. Ces deux commandes permettent d'avoir un écho de tout texte obtenu avec le moniteur sur le port série. Vous pouvez donc brancher un autre Amiga ou une imprimante série ; il vous suffit de sélectionner 9600 bauds, 1 stopbit, et vous aurez la joie de voir vos désassemblages, dumps ou autres s'inscrire sur votre terminal ou imprimante, alors que l'AmigaDOS n'existe plus... Toutes les autres commandes (il y en a le double par rapport à la version 1.0, je dis ça aux accros du programme) sont faciles à utiliser et ce serait pénible autant pour vous que pour moi de les expliquer, puisque de toute façon leurs syntaxes et leurs buts sont expliqués directement dans le T-Mon. Et enfin, petite remarque importante -- étant donné qu'il est absolument impossible de savoir quel type de clavier vous possédez (même l'AmigaDOS ne le sait pas), et étant donné que je suis Français, T-Mon utilise par défaut le clavier AZERTY. Cependant, comme je tiens à ce que le programme soit convivial et distribuable, il suffit d'appuyer sur F10 pour passer en clavier QWERTY. Un autre appui sur F10 repasse en AZERTY. V - Pour les petits curieux... Pour ceux qui voudraient en savoir plus sur la manière dont le directory du format T-DOS est construit (si vous voulez programmer une application qui puisse sauver directement des fichiers T-DOS ?), voici quelques explications supplémentaires... Le directory du format T-DOS est situé sur une seule piste, la piste 0 upper side, autrement dit les secteurs 11 à 21 de la disquette. Cela peut rappeler les directory des 8-bits ou des compatibles PC, mais cela permet une grande rapidité de chargement. Les 16 premiers octets (la première 'ligne' de ce directory) sont occupés de façon spéciale : les 4 premiers contiennent la marque "TDOS" en majuscules qui sert à reconnaitre une disquette au format T-DOS. Les 12 derniers octets sont utilisés de manière interne et variable, ils indiquent notamment si la piste 40 est réservée ainsi que la version du système de fichier T-DOS (pour le moment c'est toujours V1 vu qu'il marche très bien) ; surtout ne changez jamais ces flags ! Les fichiers commencent donc au 16eme octet de ce directory (la deuxième 'ligne') et vont jusqu'à la fin de celui-ci : le format T-Dos permet donc de stocker un maximum de 351 fichiers par disquette, ce qui devrait je crois être largement suffisant. Chaque fichier occupe 16 octets dans le directory, voici comment : les 8 premiers octets, on peut s'en rendre compte facilement, contiennent le nom du fichier, complété avec des zéros (et il doit toujours en être ainsi !) ; les 4 octets qui suivent indiquent la longueur exacte du fichier ; les 2 octets suivants indique le numéro du secteur de départ du fichier, et les 2 derniers octets indiquent le nombre de secteurs occupés par le fichier. Ce nombre aurait pu être déduit de la longueur du fichier mais c'est plus simple, de plus je n'ai rien trouvé d'autre à mettre dans ces deux derniers octets ! La fin du directory arrive bien entendu presque toujours avant la limite fatidique des 351 fichiers ; dans ce cas un zéro comme premier octet de la 'ligne' indique la fin d'un directory. Il faut aussi savoir que la première piste disponible pour les fichiers est la piste 1, lower side (qui commence au 22eme secteur de la disquette, ce qui se situe juste après le directory. Un exemple de ce dernier contenant les fichiers 'MAIN' (12532 octets) et 'MUSIC' (195632 octets) se présenterait donc de la façon suivante : +00 54444F53202A2053 79737465 6D20 5631 TDOS * System V1 ------nom------ -taille- dept nb --nom--- +16 4D55534943000000 0002FC30 0016 017F MUSIC........... +32 4D41494E00000000 000030F4 0195 0019 MAIN............ +64 0000000000000000 00000000 0000 0000 ................ .. ... On voit donc que le premier fichier 'MUSIC' est enregistré à partir du secteur $16 (22), sur $17F (383) secteurs, ce qui correspond à 383*512 =196096 ($2FE00) octets, nécessaires à contenir les 195632 ($2FC30) octets qu'occupe le fichier (196096 est le multiple de 512 supérieur de 195632 !). (Le TrackmoDOS lors du chargement du fichier réservera bien entendu 195632 octets de mémoire et non pas 196096 !!). Le fichier 'MAIN' est enregistré à partir du secteur 405 ($195), ce qui correspond à 22+383, 22 étant le secteur de départ du fichier 'MUSIC' et 383 la longueur de ce dernier, on peut donc constater que 'MAIN' est enregistré juste après 'MUSIC'.. C'est cela que j'appelais 'enregistrer séquentiellement'. La quatrième ligne (+64) est à zéro ce qui indique la fin du directory, mais attention, seul le premier octet a pour fonction de marquer cette fin, après un reformatage il se pourrait que les autres octets de la ligne aient une valeur quelconque. C'est donc le premier octet de la ligne à zéro et lui seul qui indique la fin du directory. Si vous désirez lire un fichier, il y a quelque chose d'important à prendre en compte : si il y a une étoile entre "TDOS" et "System V1" dans la ligne de flags du directory, comme c'est le cas ici, cela signifie que la piste 40 est reservée, comme expliqué dans le chapitre 2 concernant le gestionnaire. Cela signifie en clair que vous devez 'sauter' la piste 40 lorsque vous chargez un fichier. Pendant la démo, le directory se trouve toujours à l'adresse $1800, exactement comme il est stocké sur disque, cette adresse est garantie de rester la même pour les futures versions de TrackmoDOS. Les routines de chargement utilisent le directory en mémoire et ne le lisent sur la disquette qu'en cas de changement de disk (que vous aurez demandé, d'ailleurs); vous pouvez donc, si cela vous est utile, modifier ce directory à l'adresse donnée, les routines de chargement utiliseront le directory modifié. Exemple, il n'est pas prévu par le TrackmoDOS que l'utilisateur charge directement une piste ; mais si vous y tenez absolument, il vous suffit d'ajouter un fichier, en mettant un nom, la longueur à charger, le secteur de départ et le nombre de secteurs -- il suffit alors d'appeler Load ou LoadAlloc avec le nom créé pour lire les secteurs voulus ! Tout cela peut paraitre bien compliqué, ca l'est. C'est d'ailleurs pour cela que j'ai en projet la création d'une library utilisable sous AmigaDOS et qui permettra de jouer au gestionnaire tout seul comme un grand... Wait and see ! VI - Compatibilité antérieure Il me semble bon de parler d'un autre problème que la compatibilité avec les différents Amigas, il s'agit de la compatibilité avec les versions ultérieures du TrackmoDOS... Bon, bien entendu, si vous programmez une démo, le code actuel du TrackmoDOS sera enregistrée avec votre démo, vous n'aurez donc jamais du problème : si ca marche, ca marchera... Mais si vous comptez retravailler un programme fonctionnant sous T-DOS, vous voudrez certainement profiter d'une version supérieure qui sortira (si je suis encore vivant !) probablement dans quelques mois.. Donc, voici quelques remarques concernant ce qu'il faut faire et surtout ne pas faire en programmant sous Trackmo-DOS : J'en ai dêja parlé, il n'est pas recommendé du tout de charger des données à une adresse "absolue" (fixe) ; la mémoire telle que le TrackmoDOS la gère pourrait être corrompue (TrackmoDOS gère la mémoire comme l'AmigaDOS, avec le principe des memchunks un peu partout dans la mémoire, et on n'est pas censé les effacer). Donc, même si vous pouvez charger directement avec Load(), je vous conseille vivement d'utiliser les allocations dynamiques. La zone mémoire (fixe, car elle en-dehors de la mémoire 'allouable' par TrackmoDOS) entre $00001100 (fin du code du Trackmo-DOS) et $00001800 (début du directory) est pour le moment inoccupée. L'espace libre est évidemment prévu pour l'extension future du TrackmoDOS tout en garantissant l'adresse de début du directory ; donc, si vous comptez conserver la compatibilité avec une version supérieure, ne touchez pas à cette zone. Par contre, si vous programmez une démo destinée à être utilisée avec une version fixe (puisque celle-ci est enregistrée avec), vous pouvez vous servir de cette zone pour stocker des variables ou tout ce qui vous chante. Enfin, une remarque qui n'a pas grand chose à voir avec la compatibilité, mais bon : il est inutile de détourner un offset de fonction dans tdos.toolbox, par exemple changer l'adresse de MemAlloc pour contrôler vous-même la gestion de la mémoire, puisque LoadAlloc() et autres l'appellent -- Les fonctions du TrackmoDOS, lorsqu'elles s'appellent les unes les autres, le font directement, sans passer par l'offset dans tdos.toolbox (ben quoi, je programme comme je veux !!) ... VII - Changements de la version 2.2 à la version 3.0 - gestionnaire : entièrement reprogrammé - TrackmoDOS : _ gestion de la mémoire reprogrammée pour utiliser toute la mémoire disponible _ se renseigne désormais sur le hard, et par le système (juste avant de l'éliminer !) pour éviter des problèmes de compatibilité (le TrackmoDOS tourne d'ailleurs très bien sur kickstart 2.0 ou 3.0) _ fonction ajoutée : MemAvail _ champs ajoutés : totalchip, totalfast, agnustype, denisetype displaytype, proctype, coproctype, kickver - T-MON : _ redesigné _ commandes du debugger et gestion trackmodos ajoutées _ programme réarrangé VIII - Conclusion Il doit vous tarder (du moins je l'espère !) d'utiliser le TrackmoDOS, de toute façon je pense n'avoir rien oublié. J'espère que ce programme vous permettra de programmer facilement une Trackmo, en vous concentrant sur la partie 'noble' de votre code, à savoir les effets, le design etc. Vous remarquerez très certainement que le gestionnaire est "self- detaching", il se 'décroche' du CLI ou du Shell... Cela veut dire que bien que le gestionnaire tourne, il rend en même temps la main au CLI/Shell que vous pouvez continuer à utiliser ou même le fermer, il n'y a pas de problème. Le programme ne met aucun message de copyright visible sur votre disquette ; le choix vous est laissé d'indiquer ou non mon nom dans votre démo (un petit "Disk routines by Poison/NOVA" suffira !) -- vous pensez peut-être que l'on vous prendra pour un lamer si vous mettez que c'est quelqu'un d'autre qui a programmé les routines disk ; personnellement je pense que c'est au contraire les lamers qui ne donnent pas de crédits, ce ne sont pas les routines disquette qui feront que votre démo aura du succés ou non (enfin, un petit peu quand même ! c'est toujours agréable, une démo qui passe sur A500+ et qui reconnait les drives externes...), donc me donner un petit crédit, à l'égard du boulot que m'a donné la programmation de cet utilitaire et le temps qu'il va vous faire économiser, ne sera pas grand chose... Pour les swappers fous, plusieurs remarques : d'abord, le programme est DEJA compacté, comme ça je suis sûr que vous ne me foutrez pas le multitâche en l'air avec des compacteurs trisomiques ; ensuite, n'oubliez AUCUN fichier !! Il vous faut donc inclure : "trackmodos" (le programme principal), "trackmodos.doc.french" (la presénte documentation française), "trackmodos.doc.english" (la doc en anglais), "libs/diskfont.library" (nécessaire au gestionnaire pour utiliser sa propre fonte, il faut l'inclure ou le programme ne se lancera pas !), "fonts/poison.font" et "fonts/poison/8" (la fonte du gestionnaire, à inclure obligatoirement aussi !). N'oubliez evidemment pas non plus le fichier "tdos.i" qui contient tous les includes nécessaires à la programmation du TrackmoDOS en assembleur avec AsmOne, Trash'm-One ou Devpac. Je le repète, incluez la documentation ou le programme n'aura aucune utilité (il n'y a que les lamers qui font des packs sans les documentations, pour n'importe quel utilitaire ca revient à éliminer au moins une partie de ses fonctions, les moins abordables directement) Une dernière chose, j'ai parlé de l'utilisation du TrackmoDOS pour la conception d'une démo, mais tout cela s'applique bien entendu à la création d'un musicdisk, d'un mag, ou pourquoi pas d'un jeu, le principe est le même ! Si vous voulez me contacter, pour me faire part de vos remarques, suggestions, idées d'extensions futures, demandes en mariage, dons en liquide, ou je ne sais quoi, prenez donc votre plume et écrivez à : Poison / NOVA MARTY Emmanuel 10 Impasse du Romarin 34920 Le Crès FRANCE. Tel : (+33) 67-70-80-65 Si vous avez un problème urgent... Il est même autorisé de m'envoyer des disquettes (par exemple avec une de vos démos utilisant le TrackmoDOS !), je réponds à tout le monde. Un petit hello à Fireblade, donc.. Espèrons que la version 3.0 de son TDM qui est aux dernières nouvelles en cours d'écriture (même s'il ne laisse filtrer aucune information) et qui semble assez prometteuse reviendra se lier à mon programme qui pour le moment fait cavalier seul... Sinon il faudra que j'écrive une commande pour pallier à son absence mais ca fait chier ! Merci à Coronal/NOVA, Mushies/NGC, Cyprien, Xann/SILENTS, Blue Silence/NOVA, Nicolas, Speedpower/PROFECY, Fever, Audiomonster/MELON DESIGN, DTS/Nova, Kyle/ABYSS, tous mes autres contacts et surtout ma Laetitia pour le 'moral support'... Petit hello à Colin Fox et Bruce Dawson, les auteurs de la req.library que mon programme n'utilise plus (le design a vaincu la flegme)... Il ne me reste plus qu'à vous souhaiter bonne chance avec ce programme, rendez-vous dans une version future ! - Poison of Nova ______________________________________________________________________________ C'EST FINI !! ______________________________________________________________________________