Sponsors

FacebookTwitterGoogle Bookmarks

ÇA MARCHE PAS TOUJOURS Tout d'abord, un programme susceptible d'être installé dans le boot doit être écrit entièrement en code relatif au PC (Program Counter) car il doit être totalement indépendant de l'adresse de chargement. En effet, on ne peut pas savoir avec exactitude où le programme boot sera chargé dans la mémoire de l'Amiga. De plus, ce programme ne sera pas corrigé selon son adresse de chargement comme le serait un fichier exécutable "normal". Je vous rassure, il n'est pas du tout difficile d'écrire un tel programme grâce au jeu d'instructions très complet du 68000; il suffit seulement d'y penser. Voir à ce sujet comment est écrit le programme d'exemple. Voyons maintenant comment AmigaDos se débrouille avec des fichiers exécutables. En effet, tous les programmes pour Amiga ne sont pas écrits en code relatif, et plus encore, un programme en C par exemple ne pourra jamais l'être. Et pour corser le problème, l'Amiga est une machine multi-tâches, ce qui signifie que plusieurs programmes peuvent être chargés en même temps en mémoire, le seul critère étant la place disponible et non l'adresse de chargement. Toutes ces contraintes font que les fichiers sur Amiga sont eux aussi très particuliers.

Click image to download PDF

AMIGA NEWS TECH numero 09 (02-1990)

Document sans nom F. Mazue
Tout nouW bj c
le SinusScroHI
Little Zeus **
Un autre scrolli vertical celui-là
'heirhardSaratt
REQUESTER
Question: Monsieur, Non, Amiga PC n'est pas bel et bien muet ! Suite au rubrique courrier de votre revue numéro 1, page 78 où vous répondez à Lionel Galerneau de Ros- nay. En haut de la carte PC-XT vous avez deux pins pour la sortie son que vous devez raccorder au prise audio à l'arrière du moniteur 1084. Ainsi, on a le «son » PC sur notre machine adorée. Ceci est d'ailleurs écrit dans la notice en « anglais» de la passerelle. D'autre part je trouve inadmissible que pour une revue ayant le nom « Commodore Revue » même totalement indépendante, que vous n 'ayez pas été vous renseigner chez Commodore avant de répondre à la question si vous ne connaissiez pas la réponse. Car il ne faut pas oublier quand même que vous avez un tirage de 35.000 exemplaires et que vous êtes plus ou moins lus par tous les Amiga- maniac. Respectueusement vôtre,
Kemal Karatas, Orange
Réponse : Cher monsieur, merci pour cette précision technique qui fera certainement très plaisir à Lionel Galerneau, de Rosnay. Puis-je toutefois oser me permettre de vous rappeler que les mots « rubrique » et « prise » (même audio) sont du genre féminin, ce qui donne : « suite à la rubrique... » et »... que vous devez raccorder à la prise audio...». Celà dit, pour ce qui est de nous renseigner chez Commodore, croyez bien que nous y pensons chaque fois ou presque que nous ne pouvons répondre nous-même à une question. Vous êtes tombé sur l’exception qui confirme la règle, voilà tout...
O
Question : Tout d'abord, bravo pour tous vos articles antérieurs, présents et à venir. Je n 'ai jamais vu une telle clarté dans un article. Je tiens à poser plusieurs petites questions qui je pense satisfairont bon nombre de lecteurs. 1 Pour Little Zeus: comment se procurer le fameux SmartDisk dont vous faîtes l'éloge (DomPub or not DomPub) ? 2 Toujours Little Zeus: bravo pour la Tube-Intro (je ne l'ai pas encore tapée, mais cela ne saurait tarder), elle est claire et nette, mais je me permets cependant de poser quelques suggestions. Tout d'abord, aurons-nous droit à de la musique dans la Tube-Intro ? Ensuite, il apparaît que certaines démos sont compilées et il serait intéressant dans tous les sens du terme d'avoir une compilation de notre fameuse Tube-Intro (avec listing à l'appui bien sûr) et de pouvoir avec le fameux double-clic lancer celle-ci. Je pense que seulement une partie du programme est compilée et que au début de celui-ci on trouve la partie décompilation. Merci d'avance. 3 Pour Little Zeus ou autres: étant très intéressé par les boot-intros (et non pas virus-intros...) je serais très content, comme d'autres d'ailleurs, de connaître la nature exacte d'un boot- secteur, la nature exacte d'un listing assembleur devant s'installer en boot (supposant que celui-ci doit avoir une structure de programmation particulière), le moyen, après fabrication de notre routine, de l'installer sur le boot-secteur. Il apparaît aussi que dans le cadre d'une présentation (toujours sur le boot-secteur) avec sélection d'un choix pour une
compile par exemple, qu 'un code de retour est généré, code qui est pris en compte par une deuxième routine pour lancer ledit choix. Si vous avez eu en mains une de ces compiles, vous devez comprendre de quoi je parle. Je serais donc preneur d'amples explications à ce sujet. 4 Pour Short- Circuit: il apparaît que dans Commodore Revue numéro 16, le schéma d'implémentation du sélecteur de drive soit complètement faux! Il est aussi regrettable pour ma part en tout cas, de ne pouvoir jouer au fabuleux soft qu 'est Heroes of the Lance, qui comme tout le monde le sait, ne boote qu'en KickStart 1.2. Alors, aurons-nous un jour prochain l'agréable surprise de trouver dans vos colonnes un schéma d'un double KickStart ? Bien d'autres questions pourraient venir se greffer à cette longue liste, mais ne voulant pas m 'incruster, ce sera pour plus tard. Espérant des réponses à toutes mes questions, je termine par ceci: bravo à toute l'équipe! Amigalement vôtre,
Jean-Michel Flament, Fresnes
Réponse: Pffff, que de questions ! La majorité a déjà trouvé réponse dans ce numéro de Commodore Revue (structure du boot secteur, programme de boot, sélecteur de KickStart), ou dans nos plus anciens numéros (musique et compilation pour la Tube-Intro). Pour ce qui est du menu de compile, de deux choses l’une : soit le menu est en boot, et à ce moment-là, il est impossible qu’une seconde routine externe au programme charge la démo choisie (cela doit être fait par le programme lui-même), soit il est appelé depuis la Startup-Sequence par exemple, et il lui suffit de renvoyer dans dO, avant le rts final, le numéro de la touche appuyée comme code d’erreur, le script appelant n’ayant plus qu’à réagir en fonction de ce code. Concernant le montage publié, il est effectivement faux. Ceci est dû à une erreur de maquette lors du choix des documents (schémas), erreur qu’Olivier Mangon nous a d’ailleurs signalée et que nous aurions dû réparer depuis longtemps... Toutes nos excuses, cela ne saurait tarder.
EDITO
L’Amiga NewsTech de ce mois-ci est particulièrement bien fourni. Tellement que l’initiation à l’assembleur de Max s’en retrouve exceptionnellement réduite à deux malheureuses petites pages et expulsées du cahier ! Ça commence à bouger, on reçoit des propositions d’articles à ne plus savoir quoi en faire : merci. Bonne nouvelle pour les maniaques de l’assembleur : le mois prochain marquera la naissance d’une série d’articles intitulée « le Blitter de B à R », qui vous dira tout ce que vous avez toujours voulu savoir sur cette fabuleuse petite puce sans jamais oser le demander... Ce serait dommage de rater ça, non ?
Stéphane Schreiber
mnmn ????
TRUCS ET ASTUCES AMIGADOS
* ** CLS ***
Prograirme d'effacement de CLI ou Shell courante par F MAZUE
la fenêtre
; offsets d'exec.library
OldOpenLibrary = -408 CloseLibrary = -414
Il est paradoxal qu'un ordinateur de la classe de l'Amiga ne possède pas de commande pour effacer une fenêtre CLI : l'alias Clear du Shell ne satisfait certainement pas tout le monde. En tout cas, pas ceux qui ne possèdent pas le WorkBench 1.3! De plus, Clear efface les fenêtre Shell mais pas les fenêtres CLI.
PLUS PROPRE !
E programme qui suit répare cette petite L lacune.
Son principe est très simple : après avoir ouvert la dos.library, le programme recherche le canal de la fenêtre à partir de laquelle il a été appelé, puis y écrit une séquence de caractères de contrôle (cf. Documentation sur les entrées sorties de l'Amiga) : £9b,";H" Ramène le curseur ligne 1 colonne 1 (HOME); £9b,"J" Efface la fenêtre à partir du curseur.
Pour terminer, la dos.library est fermée et le programme rend la main.
Le programme a été écrit avec Devpac 2 mais ne présente pas de problème de compatibilité avec le préhistorique K-Seka que ceux qui aiment s'embêter affectionnent...
Enfin le code objet de ce programme est entièrement relogeable, ça peut toujours être utile. Mieux il est complètement réentrant. En d'autres termes, vous pouvez le rendre résident par la commande Résident Cls Pure ADD
placée dans votre Startup-Sequence, ou bien tout simplement en positionnant le bit p dans les attributs de protection par la commande Protect Cls +p
L'avantage de ceci est que l'AmigaDOS n'ira plus chercher la commande Cls sur disque mais en mémoire, ce qui évitera la très désagréable séance de "disk jockey" aux malheureux possesseurs d'un seul et unique drive.
Encore quelques remarques : il est parfaitement possible de modifier très légèrement ce programme afin qu'il permette de changer la couleur d'écriture ou celle du fond de la fenêtre. A titre d'indication, voici quelques codes utiles à placer au label "début" dans le listing :
- définition de la couleur et du style d'écriture : $ 9b, style, cl, c2, "m"
où style est un caractère ÀSCII pouvant être :
"O" : écriture normale;
"1 " : écriture grasse;
"2" : écriture italique;
"3" : écriture soulignée; c1 est une chaîne de caractères ASCII pouvant être :
"30" à "37" : couleurs du texte de O à 7 c2 est chaîne de caractères ASCII pouvant être : "40" à "47" : couleur du fond de O à 7
- rendre le curseur invisible (pour faire une blague?) : $ 9b, "O", "p"
- rendre le curseur visible : $ 9b, "p"
Et il y en d'autres...
Frédéric Mazue
; offsets de dos.library
Output = -60 Write = -48
start : tst.l dO
beq
erreur
move.l $ 04,a6 ;
lea dosname(pc),al jsr OldOpenLibrary (a6) ; beq erreur ;
move.l d0,a6 ;
jsr Output (a6) ;
lea début(pc),aO move.l a0,d2
moveq (f in-debut),d3
jsr Write (a6)
move.l a6,al
move.l $ 04,a6
jsr CloseLibrary (a 6)
erreur:
rts
dosname: dc.b 'dos.library', even
début: dc.b $ 9b,M;HM
dc. b $ 9b, "J"
fin:
si dO contient 0, c'est que le prograirme a été lancé depuis le WORKBENCH, il n'y a donc pas de fenêtre à effacer...
VITE, fuyons le GOUROU
execbase dans A6
ouverture de dos.library
ça n'a pas marché on arrête tout
dosbase dans a6
cette fonction recherche le canal de la fenêtre CLI ou Shell courante, le résultat est dans dO ET dans dl
adresse des chars de contrôle à écrire dans d2
ceci est une particularité du 68000 : ces deux instructions occupent le même nombre d'octets que la seule instruction move.l debut,d2 le temps d'éxecution est le même l'avantage est que le code objet sera relogeable nombre de caractères dans d3
pas de parenthèses avec K-SEKA effacement de la fenêtre
dosbase dans al execbase dans a6 fermer dos.library
et (déjà) c'est fini
ATTENTION, aux majuscules !
Lancan ????
Imigri
TRANSACTOR
Rôle
Word
Long
EndSkip
Flags
Long
Byte
Version
Type
Name
IDString
Init
Byte
Byte
Long
Long
Long
M inute, je m'explique.
A ces mots, je vois les intéressés se lever, prêts à me balancer leur clavier en pleine figure. Bon, ils ont quand même droit à quelques explications.
Le virus-killer des Zeus-Brothers est calqué sur le fonctionnement du SCA (Swiss Cracking Association), le plus primitif : il reprogramme les vecteurs CoolCapture et DolO. C'est bien et ça empêchera facilement les trois quarts des virus de se reproduire (je ne me contredis pas, seule la moitié sera réellement tuée) mais reste l'autre quart.
Enumérons quelques-uns de ces phénomènes :
- le byte bandit est l'exemple même du virus étanche aux remontrances des Zeus-Brothers : il ne reprogramme ni le CoolCapture, ni le DolO général. Il s'attaque à l'interruption de niveau 5, au vecteur DolO propre au trackdisk.device et enfin, installe une structure résidente. Ici, je sens que le public néophyte commence à se demander quel langage je parle. Ne vous en faites pas, je m'expliquerai sur ces points sombres un peu plus tard;
- le Byte Warrior (ou DASA) est en fait un virus-killer... qui plante l'ordinateur. Après le traitement à la sauce Zeus-Brothers, il ne pourra certes plus se reproduire, mais ses effets pernicieux demeureront : lui aussi installe une structure résidente, et de plus, il affecte les vecteurfe CoolCapture ET Cold- Capture (patience, les excités du clavier, je vais venir aux explications);
- 'IRQ est un cas à part : il ne s'installe pas sur le bootblock mais se greffe sur les fichiers exécutables de votre disquette. Je sais peu de choses sur son mode de fonctionnement sauf que lui aussi fonctionne avec une interruption (IRQ signifie Inter- rupt Request).
C'EST PARTI POUR LE COURS DE L.M.
Comment, quoi, que vois-je? Nos chers Zeus-Brothers seraient-ils tombés malades? Que leur arrive-t-il? Ils nous avaient habitué à une programmation de qualité avec leur Tube-lntro et voilà qu'ils font preuve d'un manque de maturité flagrant en osant faire publier un virus-killer (un tueur de virus pour les francophones) qui, non content d'être lui-même un virus, ne guérira pas plus de cinquante pour cent des disquettes infectées.
VIRUS KILLER? MON GEIL!
C'est parti pour le voyage à l'intérieur de l'Amiga tm (attention, ça va gazer : je me suis mis un petit Hige- lin sur la platine). A titre de renseignement, toutes les explications que je vais donner sont largement inspirées d'un certain livre de 639 pages qui devrait être le nouveau testament pour nous tous!
Je passerai sur le vecteur DolO général. Il est assez expliqué dans les colonnes de la Zeus-saga. Je signalerai cependant l'existence d'un vecteur DolO propre à chaque device. On le trouve à l'offset négatif -28 de la structure device.
J'ajouterai à l'existence d'un vecteur CoolCapture celle d'un vecteur ColdCapture à l'adresse Execbase + 42. Son fonctionnement diffère un peu de celui de CoolCapture. En effet, il n'y est pas permis d'utiliser le pointeur de pile (SP) et par conséquent, la routine ne peut pas se terminer par un RTS (les instructions JSR, BSR et RTS utilisant le pile). On la termine donc avec un JMP (A5).
Les structures résidentes se trouvent un peu partout en mémoire. Elles sont trouvées à l'initialisation par le premier mot suivi du premier long mot (cfr infra) et leur code est exécuté selon le mode de fonctionnement de la structure. En voici la forme :
L'ALTERNATIVE
Le programme que je propose dispose d'assez de commentaires pour être compris. Je tiens à signaler qu'il ne tue pas les virus présents sur le bootblock. Il ne fait que les tuer en mémoire. Si vous désirez ¦'nettoyer" le bootblock, le mieux (et le plus simple) est encore d'utiliser la commande install dfx: du CLI. Pour plus de renseignements, contactez moi sur bit- net : VISITEUR8 BNANDP5 1
The lazy Coder from Paralaxx
PS : A la dernière minute, j'ai remarqué qu'il restait un "bug" dans la version du programme ci-joint : il détecte et tue en effet une structure résidente appartenant au système. Cela ne provoque apparemment pas de problèmes de fonctionnement, mais le message d'avertissement est affiché à chaque fois que le programme est appelé.
MatchWord $ AFC pour que le système reconnaisse ici une structure résidente
MatchTag pointeur sur l'adresse 0 de la structure
Pour que le système vérifie qu'on aie ici une structure résidente
pointeur sur la fin de la structure
détermine le mode de fonctionnement de la structure : est-elle présente pour créer une library ou pour activer une routine?
Pointeur sur le nom de la structure pointeur sur les commentaires de la structure pointeur sur la routine à exécuter_
Taille Nom
Ça suffit pour les exemples. Les maniaques de l'assembleur sont-ils toujours à leur poste? Oui? OK.
DBQIB ????
; Ceci est un utilitaire de The Lazy Coder
; Trouve
n'Importe quel
virus résident en mémoire et le tue.
; Créé le 18 juin 1989
; Modifié le 14 août 1989 pour tuer encore plus de virus connus
; Modifié le 17 octobre
1989 pour tuer les structures résidentes
; Modifié le 10 décembre
1989
; pour traduire les comnentaires en français pour Commodore Revue.
; Compllé avec ASSEMPRO de Data-becker GnbH
clr.b
d5
; D5 sert de drapeau pour savoir si on a ; trouvé un virus.
Move.1
4, a6
jsr
- 120 (a6)
; Pas de multitâche ni d'interruption
jsr
- 132 (a6)
; durant le piogranme car certains viru ; en profiteraient.
Move.l
$ 2A(a6j ,d0
; Cherche un virus dans les vecteurs ; Cool, Cold et Warm capture
move.i
$ 2E (a6) ,dl
move.l
$ 32 (a 6), d2
add.l
dl,d0
add. 1
d2,d0
anp.l
10, dO
beq
NoVirusl
clr.l
$ 2A(a6)
clr.l
$ 2E(a6)
clr.l
$ 32 (a6)
lea
$ 22 (a6), al
clr.w
dO
move.w
$ 17,dl
; Recalcule la sonune de contrôle.
Loop:
add.w
(al)+,d0
dbf
dl,ioop
not. W
dO
move.w
dO, (al)
move.b
-l,d5
NoV i rusl
move.1
- 454(afi),dO
; Cherche un virus ayant détourné le ; vecteur DoIO()
move.l
- 460 (a6), dl
} (SCA & Byte-Warrior-DASA)
addi. 1
18,dl
; Marche avec A500 et A200 klckstart 1.2.
anp.l
d0,dl
; N'a pas été testé avec des versions ; supérieures.
Beq
NoVirus2
move.1
dl,-454 (a6)
move.b
-l,d5
NoVirus2
lea
$ 15e(a6),a0
; Cherche un virus ayant détourné ; le vecteur DoIO()
lea
Tdname,al
; spécifique au trackdisk.deviçe (Byte- ; Bandit)
movem. 1
d5 a0-al,-(a7)
jsr
- 276 (a6) ;FindName
movem.1
(a7)+,d5 a0-al
tst.l
dO
beq
NoVirus3
; Ce n'est pas normal :
; pas de trackdisk.device ???
Move.l
d0,a0
move.l
- 28 (aO) ,d0
; Voir la remarque pour le DoIO général
move.1
- 34 (aO) ,dl
sub.l
l$ ac,dl
anp. 1
d0,dl
beq
NoVirus3
move.b
• -1,d5
move.1
dl,-28 (aO)
NoVirus3:
move.l
300 (a6) ,a0
; Cherche un virus ayant installé
Loop3:
; une structure résidente en RAM
tst. 1
(aO)
beq
NoVi rus4
cmp. 1
• $ fc0000, (aO) +
; Tue sans distinction toute
bge
Loop3
; structure résidente en RAM
move.w
0,-4 (aO)
; Efface le MatchWord
move.b
-l,d5
bra
Loop3
NoVirus4
move.1
a6,a0
; Cherche un virus ayant installé
; une interruption.
Move.1
I16,d0
move.l
a0,d2
swap
d2
and.w
• $ 00ff,d2
Ioop4:
move.l
(aO) ,dl
swap
dl
add.w
$ 00ff,dl
cmp. W
$ fc00,dl
beq
OKThisTlme
; Est-ce une interruption gérée en ROM ?
Tst .w
dl
beq
OKThisTlme
; Y-a-t-il seulement interruption ?
Cmp. W
dl,d2
beq
OKThisTlme
; Est-ce une interruption traitée par EXEC
clr.l
(aO)
; Cette solution risque de planter
; mais c'est la seule que j'ai trouvée
move.b
-l,d5
OKThisTlme:
add.l
• 4,a0
dra
dO, IjOop4
NoVi rus5:
jsr
- 138 (a6)
; réinstaurer le règne des interruptions
jsr
- 126 (a6)
; et du multitâche.
Tst.b
d5
; affiche un message de type GURU
; si il y avait un virus.
Beq
NoVirus
clr.l
dO
lea
IntuitionName,Al
jsr
- 552 (a 6)
; Ouvrir intuition.library
move.l
dO,IntuitionBase
move.l
d0,a6
lea
Message,A0
clr.l
dO
move.l
80,D1
jsr
- 90 (a6)
affiche un message d'alerte
movea.1
4,a6
move.l
(IntuitionBase),al
jsr
- 414 (a6)
fermer intuition.1ibrary
NoVirus:
rts
IntuitionName:
dc. b
'intuition.library
',0
even
IntuitionBase:
dc. l
0
Message:
dc. w
180
dc. b
20
dc. b
' Il y avait un virus actif en mémoire',0,1
dc. w
232
dc. b
40
dc. b
'Il est maintenant
désactivé',0,1
dc. w
116
dc. b
70
dc. b
'Un autre utilitaire de T.L.C. from PARAU XX ! ! !',0,0
even
Tdname:
dc. b
'trackdisk.devi ce'
,0
even
nop
END
ÔTE-TOI DE LÀ, OUE J'M'Y METTE!
IQQ1B DBBB
IMIGRI
INITIATION A L'AMIGADOS
Depuis le Workbench 1.2 et à chaque nouvelle version du système, on se trouve confronté au problème de la mise à jour de la configuration de l'ordinateur. Il n'est en effet pas rare de subir des crashs et des GURUs lorsqu'on mélange les versions du système.___
n jour ou l'autre, tout utilisateur se retrouve U confronté à ce dilemne : doit-il, pour installer un logiciel, copier tous les fichiers de la disquette originale vers son disque système, ou peut-il ne copier "intelligemment" que les quelques fichiers réellement nécessaire?
La première approche semble la plus sûre, mais elle présente deux inconvénients : gaspillage de la mémoire de masse, et grande difficulté pour conserver * ' méronnement homogène, car
chaque logic«ei semble être conçu pour être le seul installé. La seconde approche semble être la plus raisonnable et la plus élégante, car elle permet de mieux utiliser les ressources de l'ordinateur et elle respecte tout le travail de configuration déjà effectué (version du système, fichier de démarrage, Preferences, pointeur, imprimante...).
Avec l'arrivée du système 1.3.2. (uniquement pour remédier à quelques bugs), je me suis attaqué à l'automatisation du processus de mise à jour d'une configuration logicielle. En fait, un système d'exploitation (ou n'importe quelle autre combinaison de programmes) satisfait rarement de manière identique tous les utilisateurs. Chacun dispose d'une marge de manoeuvre pour le configurer et l'adapter. Ô à chaque progrès, à chaque avancée, à chaque "release" tout le travail est à refaire, la majorité des utilisateurs refusera de faire évoluer sa configuration, si le gain n'est pas évident. Dans mon cas particulier, l'intérêt du 1.3.2 résidait dans la réduction des bugs liés à la mauvaise gestion du nouveau coprocesseur SUPER-AGNUS par certains programmes (dont le DiskCopy de la disquette Workbench), coprocesseur dont est équipé mon Amiga 2000 acheté récemment.
Faire une installation propre, c'est n'installer que les fichiers nécessaires, c'est-à-dire ceux modifiés ou nouveaux, sans pour autant détruire ceux qui sont le fruit de nombreuses heures d'expériences et de travail acharné.
Quels sont les fichiers de configuration? En ce qui concerne l'Amiga et son système d'exploitation, il faut accorder une attention toute particulière aux fichiers suivants :
- S.Startup-Sequence : fichier de démarrage
(équivalent de autoexec.bat sous MS-DOS);
- S.Startup . Fichier de configuration auxiliaire, exécuté depuis la Startup-Sequence pour profiter des avantages d'un processus SHELL (la Startup- Sequence est exécutée par un processus CLI, qui ne peut utiliser ni les commandes résidentes, ni les alias);
- Devs.System-configuration : fichier des paramètres gérés par le programme Preferences (couleurs du WorkBench, position de l'écran, caractéristiques du port série, choix de l'imprimante, options pour l'impression graphique, etc.). Malheureusement, ce fichier est sous forme binaire; pour en étudier le contenu, il faut faire appel au programme Preferences.
Note : le répertoire S: correspond, sauf ordre contraire (commande Assign), au répertoire Sys:S et Devs; au répertoire Sys:Devs, Sys: enfin étant le nom générique de la disquette ayant servi au démarrage : Ouf!
Avant de remplacer ces fichiers, il faut comparer la nouvelle version avec l'ancienne, pour voir ce qu'elle apporte. Si ce sont de simples détails esthétiques (genre numéro de version), on peut s'en passer ou les appliquer manuellement; si les différences sont plus importantes, il faudra vraisemblablement extraire de l'ancien fichier tout ce qui était spécifique pour l'ajouter dans le nouveau. C'est en partie pour cette raison que je recommande de toujours signaler par des commentaires adéquats les ajouts et autres modifications dans un fichier de configuration. C'est parce qu'il faut traiter ces trois fichiers avec prudence que le processus de mise-à-jour ne doit pas être totalement automatique, mais au contraire interactif. De manière similaire, c'est parce qu'il y a beaucoup de fichiers concernés qu'il doit être "intelligent" et effectuer tous les tests possibles pour ne proposer comme candidats à la mise à jour, que les fichiers réellement nouveaux.
Comment détecter ces fichiers? Plusieurs cas peuvent se présenter :
- le cas le plus simple est celui dans lequel le fichier existe sur la disquette source, mais pas sur la disquette destination;
- les fichiers de départ et de destination n'ont pas la même taille (plus souvent qu'on ne le pense, les nouveaux fichiers se révèlent être plus petits que ceux qu'ils remplacent);
- les fichiers n'ont pas la même date de création, mais ce critère n'est pas toujours fiable car bon nombre de systèmes ont une notion du temps bizarre (horloge qui n'est pas à l'heure, horloge détraquée, etc.) et bon nombre d'utilisateurs n'ont pas encore pris l'habitude de copier les fichiers avec la commande COPY ...
CLONE qui conserve la date originale et les attributs des fichiers (contrairement à la même commande COPY sans l'option CLONE). En conséquence, lorsque les dates deffèrent, il convient d'effectuer un autre test sur le contenu même des fichiers, afin de déterminer si il est resté identique.
- enfin, il y a quelques rares occasions (surtout à la suite de commandes COPY mal conduites sans l'option CLONE, ou après l'utilisation de programmes de sauvegarde qui positionnent l'attribut "archivé") où ce sont les attributs des fichiers (protégés contre l'écriture, contre la lecture, contre l'effacement, contre l'exécution, fichier script, archivé, fichier pur que l'on peut rendre résident) qui ne sont pas identiques, auquel cas, il suffit de modifier les attributs de l'ancien fichier grâcé à la commande PROTECT.
Une fois cette recherche accomplie, l'utilisateur doit avoir la possibilité de suivre la recommandation du programme (COPY ou PROTECT) ou de l'ignorer pour chacun des fichiers que la première phase aura trouvé intéressant.
Comment réaliser cette détection?
Etant donné que les tests couvrent des domaines différents, il fallait choisir un langage versatile capable de collecter et de comparer toutes les informations pertinentes sur les fichiers (taille, âge, contenu), et accessible à tous. Comme le Basic Amiga est diffusé avec la machine, tout le monde y a accès, mais est-il suffisamment puissant?
En fait, il s'avère tout à fait adapté, car il peut utiliser toutes les commandes de l'AmigaDOS grâce à la fonction "Exécuté" de la bibliothèque Dos, qui permet l'utilisation d'une ligne de commande comme ci celle-ci avait été introduite dans une fenêtre CLI SHELL. Comme on va le voir, récupérer les commandes de l'amigaDOS grâce à la routine Exécuté nous économinsera beaucoup de programmation. De plus, l'utilisation de ces commandes nous garantit un certain niveau de performance. Malgré cela, le programme net de 1 0 à 15 minutes pour établir la liste des fichiers susceptibles de mise-à-jour, c'est pourquoi de nombreux PRINT de mise au point sont encore présents dans le listing : ils permettent de mieux suivre le déroulement du programme, mais ils le ralentissent de manière notable. Mais enfin, ce n'est pas tous les jours qu'on refait son système, n'est-ce-pas?
Voici le listing programme. On se retrouve le mois prochain, si tout va bien.
B. de Mil
REM Progranme de mise à jour CCMREV
PRINT “ATTENTION : ce programme exige beaucoup de mémoire !"
PRINT FRE(O)
CLEAR ,70000 PRINT FRE(O)
REM les variables chaînes de caractères peuvent prendre REM beaucoup de place voir routine de comparaison)
DECLARE FUNCTION Exécuté* LIBRARY LIBRARY “dos.library"
REM grâce au fichier dos.tmap qui décrit les paramètres requis REM par les routines de la bibliothèque DOS,
REM l'AmigaBasic peut appeller Exécuté sans aucune difficulté REM ATTENTION : il est nécessaire de lancer l'AmigaBasic REM depuis une fenêtre CLI CHELL pour pouvoir utiliser REM cette capacité sans voir apparaître le GURU !
DEFINT a,b,i, j,u
REM économise des ! à chaque usage de variable entière astop - 0 bstop - 0 DIM r$ (15)
DIM aname$ (150), asize$ (150), aprot$ (150), adate$ (150)
DIM bname$ (150), bsize$ (150), bprot$ (150), bdate$ (150)
DIM command$ (150)
REM Déclaration des tableaux concernant les fichiers REM nom, taille, attribut, date
REM les tableaux A sont pour la disquette de départ
REM les tableaux B sont pour la destination
CLS
INPUT “repertoire de départ in$
INPUT “repertoire d'arrivée “; out$ update - 0
REM première phase: construction de la liste des fichiers FOR i - 1 TO 13 READ r$ (i)
REM pour tous les répertoires du tableau r$ contient les ncms
REM des répertoires système qui contiennent potentiellement REM des fichiers à transférer doscall(r$ (i))
REM doscall est la sous-routine qui construit les tableaux
REM de nom, taille, attribut et date de fichiers triés
REM alphabétiquement pour chaque répertoire r$
bstart - 1
FOR ii - 1 TO astop
REM pour tous les fichiers du répertoire de départ FOR iii - bstart TO bstop REM pour tous les fichiers restant du répertoire d'arrivée IF aname$ (ii) bname$ (iii) THEN REM le fichier du répertoire de départ est absent puisque REM le fichier courant du repertoire d'arrivée lui est supérieur comnand$ (update)- “copy “+in$ +r$ (i)+aname$ (ii)+" to “+out$ +r$ (i) corrmand$ (update)-conmand$ (update) +" CLONE" : REM Important ! Update - update + 1
REM on met de coté la commande à effectuer REM PRINT “new file";aname$ (ii) bstart - iii
GOTO loop:REM Arggggggggggghhh, un GOTO (j'ai honte)
REM l'instruction correcte est un NEXT ii, mais l'AmigaBasic REM ne 1'apprécié pas lorsqu'il y en plusieurs pour un seul FOR END IF
IF aname$ (ii) - bname$ (iii)¦ THEN REM le fichier existait déjà
IF INSTR(aname$ (ii),".info") o 0 AND asize$ - bsize$ THEN REM c'est un fichier .info correspondant à l'icône, si il REM n'a pas changé de taille, je préféré garder l'ancien REM qui contient les coordonnées que j'aie fixé par REM l'option Snapshot du Workbench bstart - iii
GOTO loop:REM Oui, je sais, c'est un GOTO END IF
IF asize$ (ii) > bsize$ (iii) THEN REM pas de discussion, la taille a changé
conmand$ (update)- “copy “+in$ +r$ (i)+aname$ (ii)+" to “+out$ +r$ (i) cortmand$ (upxiate)=conmand$ (update) +" CLONE":REM Essentiel ! Update - update + 1
REM PRINT “copy because of size aname$ (ii)
ELSE
IF aprot$ (ii) > bprot$ (iii) THEN REM seuls les atttributs du fichiers ont changé,
REM la conmande PROTECT suffit
command$ (update)- “protect “+out$ +r$ (i)+bname$ (iii)+" “+apcot$ (ii)
command$ (update)-ccmmand$ (update)+" ADD"
update - update + 1
REM PRINT “protect";aname$ (ii)
ELSE
IF adate$ (ii) o bdate$ (iii) THEN REM les dates sont différentes, il va falloir comparer REM le contenu des fichiers avec la sous-routine compare frcml$ - in$ +r$ (i)+aname$ (ii) fram2$ - out$ +r$ (i)+bname$ (iii)
CALL comp>are(froml$ ,frcm2$ ,différent!)
IF différent! O 0 THEN REM le contenu est différent, donc copie command$ (update)- **copy “+in$ +r$ (i) +aname$ (ii) command$ (update) -command$ (update) +" to “+out$ +r$ (i)+" clone" update - update + 1 REM PRINT “différent “;aname$ (ii)
END IF END IF END IF
ÇND If: REM syntax error
REÏÏ'souvent l'AmigaBasic rapporte une erreur de syntaxe
REM juste après l'instruction END IF d'un bloc IF..ELSE..END IF
REM lorsqu'il prend la première branche
REM il faut vérifier qu'on ne modifie pas la variable testée REM entre le IF et le END IF.
REM Parfois, ajouter une instruction bidon après le END IF REM permet de supprimer ce BUG, (car c'en est un ! !) Bstart - iii GOTO loop END IF
REM si on arrive ici, ca veut dire que le fichier du répertoire REM de départ n'a pas encore trouvé son jumeau, on va donc étudier REM le fichier suivant dans le répertoire d'arrivée NEXT iii
REM fin de la boucle sur les fichiers du répertoire d'arrivée REM ce NEXT iii est le seul -> pas de problème
comnandS(update)- “copy “+in$ +r$ (i)+aname$ (ii)+" to “+out$ +r$ (i)+" clone" REM si on est arrivé là, ca veut dire qu'on a épuisé tous les fichiers REM du repertoire d'arrivée sans y trouver celui du repertoire de départ, REM on doit donc l'ajouter à notre liste contenu dans le tableau update update - update + 1 REM PRINT “last file";aname$ (ii) bstart - bstop loop:
REM voici la cible des GOTO (Argggggggghh again)
NEXT ii
REM fin de la boucle sur les fichiers du répertoire de départ
NEXT i
ppjOBEIB HHHP
REM fin de la boucle sur les répertoires
REM deuxième phase: mise à jour sélective IF update - 0 THEN PRINT "pas de fichiers à mettre à jour"
ELSE
FOR i - 1 TO update-1
REM pour toutes les conmandes enregistrées COLOR 3,2 PRINT “OK **;
COIOR 1,0
PRINT * pour executer “;conmand$ (i) ;
INPUT ok$
REM demander l'approbation de l'utilisateur IF UCASE$ (ok$ ) > “N" THEN REM si l'utilisateur ne répond pas N ou n x - Exécuté*(SADD(conmand$ (i)+CHR$ (0)), 0, 0)
REM on demande à l'AmigaDos d'éxecuter la commande END IF NEXT i END IF
fin:
LIBRARY CLOSE
REM il est très important de fermer une bibliothèque si on l'a ouverte END
DATA "c ", "devs ", "devs printers ", "devs keymaps ", "Expansion "
DATA "fonts ","1 ","libs ", "Prefs ","s ","System ","Utilities "
REM il est plus pratique de mettre le nom des répertoires système REM dans une série de DATA à lire dans la boucle principale
SUB doscall(dir$ ) STATIC SHARED in$ , out$
SHARED anameS(),asize$ (),aprot$ (),adate$ ()
SHARED bnameS(),bsize$ (),bprot$ (),bdate$ ()
SHARED astop,bstop
REM doscall est la sous-routine qui construit les tableaux REM de nom, taille, attribut et date de fichiers triés REM alphabétiquement pour chaque répertoire r$
REM à la fois pour le départ et pour la destination
REM toutes les variables non partagées par SHARED sont locales.
REM Elle utilise intensivement LIST et SORT que vous pouvez REM rendre résident ou (au moins) copier en RAM: pour REM aller plus vite. Vous pouvez aussi ajouter des tuffers REM sur la source et la destination grâce à la commande REM AmigaDos ADDBUFFERS. Par exemple ADDBUFFERS DFO: 20 REM ajoute 10 K-octets au lecteur de disquettes DFO:. Temp$ - “list * + in$ + dir$ + “ files nohead to RAM:temp"
PRINT “doing tempS
REM construction d'une première ligne de commande AmigaDos appropriée x - Exécuté*(SADD tempS+CHR$ (0)), 0, 0)
REM liste des fichiers par nom, attributs, taille et date x - Exécuté4(SADD(“sort ram:temp ram:in"+CHR$ (0)), 0, 0)
REM tri par la commande AmigaDos SORT sur le nom des fichiers OPEN "RAM:in" FOR INPUT AS 1 REM lecture du fichier trié i - 0
WHILE NOT EOF(1)
REM tant qu'on n'a pas atteint la fin du fichier i -i +1
LINE INPUT l,a$
REM on lit une ligne complète
j - INSTR(a$ ," “)
anameS(i) - UCASE$ (I£FT$ (a$ ,j-1))
REM le nom s'arrête au premier blanc WHILE MID$ (a$ ,j,l) - n * j - j + 1 WEND
REM la taille commence après le dernier blanc (j) asize$ (i) - MID$ (a$ ,j,33-j) aprot$ (i) - MID$ (a$ ,34,8)
REM les attributs occupent toujours le même emplacement adate$ (i) - MID$ (a$ ,43)
REM idem pour la date
REM PRINT i;" - anameS(i);TAB(30);asize$ (i),aprot$ (i),adate$ (i) IF INSTR(anameS(i),".fastdir") o 0 THEN REM si il s'agit d'un fichier temporaire de CLIMate,
REM ne pas en tenir compte
i - i-1
END IF WEND
astop - i
REM astop représente le nombre de fichiers dans le répertoire de départ
REM même procédure pour le répertoire d'arrivée
tempS - “list * + out$ + dir$ + “ files noheac} to RAM:temp"
PRINT “doing “;tempS
x - Exécuté*(SADD(temp$ +CHR$ 0)), 0, 0)
x - Exécuté*(SADD(“sort ram:temp ram:out"+CHR$ (0)), 0, 0)
OPEN “RAM:out" FOR INPUT AS 2
i - 0
WHILE NOT EOF(2)
i - i+1
LINE INPUT 2,a$
j - INSTR(a$ ," “)
bnameS(i) - UCASES(LEFT$ (a$ ,j-1))
WHILE MID$ (a$ ,j,1) - “ “
j “ j+1
WEND
bsize$ (i) - MID$ (a$ ,j,33-j) bprot$ (i) - MID$ (a$ ,34,8) bdateS(i) - MIDS(a$ ,43)
REM PRINT i;" - ”;bname$ (i);TAB(30);bsize$ (i)fbprotS(i),bdate$ (i)
IF INSTR(bname$ (i),".fastdir") > 0 THEN
i - i-1 END IF WEND
bstop - i
REM bstop représente le nombre de fichiers dans le répertoire d'arrivée
CLOSE 1, 2 KILL “RAM:temp"
KILL"ram:in"
KILL “ram:out"
REM nettoyage END SUB
SUB compare(firstS,seconds,result%) STATIC
REM pas de variables partagées autre que les paramètres REM compare est la sous-routine qui va lire 10 Kilo-octets REM des fichiers de départ et d'arrivée avec un simple test REM il est possible que la fonction INPUTS ne lise pas REM de manière fiable 10240 caractères, car elle est REM documentée comme détectant le caractère CTRL-C corme REM la fin de son entrée
REM enfin, si ce CTRL-C est à la même place dans les deux
REM fichiers, cela reste correct
REM PRINT “camparing “;first$ ;" secondS;"
OPEN first$ FOR INPUT AS 1 LEN-2048 OPEN second$ FOR INPUT AS 2 I£N-2048
REM c'est à cause de ces buffers 2048 et des variables REM frcml$ et from2$ que la fonction CI£AR,70000 est REM nécessaire au début du programme resuit% - 1
IF LOF(l) > 10240 THEN size% - 10240 IF UDF(1) 10241 THEN size% - LOF(l)
REM ARGGGGGGGG BUG in IF..THEN..ELSE..END IF frcml$ - INPUT$ (size%,1) fram2$ - INPUTS(size%,2)
IF fromlS - from2$ THEN result% - 0
REM c'est le test essentiel de cette routine
REM si INPUTS ne vous parait pas fiable, vous pouvez
REM utiliser une boucle du style
REM tant que pas fin de fichier de 1 et de 2
REM lire un caractère de 1
REM lire un caractère de 2
REM comparer
REM si différent :
REM sortir de la sous-routine REM sinon :
REM continuer
REM cela promet de prendre beaucoup de temps REM même s'il y a des buffers,
REM cette routine est déjà assez lente comme ça REM PRINT TAB 56); result%;" (size-";LEN(FRCMl$ ))"
CLOSE 1, 2 END SUB
Envie d'écrire dans l'Amiga NewsTech ? Toute proposition est la bienvenue à : Commodore Revue - ANT 1 bis rue de Paradis - 75010 Paris
IPBEID HHHia
ift
A
P
PL
ICAT
INSTALLATEUR DE BOOT
Une disquette formatée sous AmigaDOS comporte 1760 secteurs d'une capacité de 512 octets chacun. Sur ces 1760 secteurs, 1 758 sont utilisés par AmigaDOS pour gérer les fichiers et 2 sont soit inutilisés, soit contiennent le programme boot et la disquette est dite "autoboot".
E programme boot, que l'on met en place sur la L disquette grâce à la commande CLI "install" est ainsi constitué :
- on trouve d'abord 4 octets qui ne sont rien d'autre que le mot DOS, et qui permettent à l'ordinateur de s'assurer que la disquette a bien été formatée par lui;
- on trouve ensuite 4 octets qui sont une somme de contrôle (Checksum en anglais) et qui est la preuve pour l'ordinateur qu'il s'agit bien d'une disquette autoboot;
- viennent 4 autres octets formant le long mot $ 00000370: cette valeur est le numéro du bloc racine (RootBIock), premier secteur du catalogue très particulier que l'AmigaDos utilise;
- enfin, on trouve le programme d'amorçage proprement dit, programme très court (mais néanmoins indispensable) qui ne fait que rechercher l'adresse de base de la dos.library résidente en Rom.
Tout ceci est très loin d'utiliser entièrement les
I 024 octets des 2 secteurs boot, et il est ainsi possible de venir y greffer un petit programme de son crû, histoire de personnaliser ses disquettes.
II subsiste quand même un problème : vous avez écrit un joli programme sur votre assembleur préféré et vous l'avez sauvegardé sous forme d'un fichier exécutable. Comment transférer ce programme dans les secteurs boot?
Réponse : il suffit d'utiliser notre programme du mois, Bootlnstall - sous réserve que cela soit possible.
ÇA MARCHE PAS TOUJOURS
Tout d'abord, un programme susceptible d'être installé dans le boot doit être écrit entièrement en code relatif au PC (Program Counter) car il doit être totalement indépendant de l'adresse de chargement. En effet, on ne peut pas savoir avec exactitude où le programme boot sera chargé dans la mémoire de l'Amiga. De plus, ce programme ne sera pas corrigé selon son adresse de chargement comme le serait un fichier exécutable "normal".
Je vous rassure, il n'est pas du tout difficile d'écrire un tel programme grâce au jeu d'instructions très complet du 68000; il suffit seulement d'y penser.
Voir à ce sujet comment est écrit le programme d'exemple.
Voyons maintenant comment AmigaDos se débrouille avec des fichiers exécutables.
En effet, tous les programmes pour Amiga ne sont pas écrits en code relatif, et plus encore, un programme en C par exemple ne pourra jamais l'être. Et pour corser le problème, l'Amiga est une machine multi-tâches, ce qui signifie que plusieurs programmes peuvent être chargés en même temps en mémoire, le seul critère étant la place disponible et non l'adresse de chargement.
Toutes ces contraintes font que les fichiers sur Amiga sont eux aussi très particuliers. Ils ne sont pas constitués d'un entête suivi du programme comme sur les vieux ordinateurs 8 bits, mais constitués d'une ou plusieurs sections appelées "Hunks". Le premier hunk d'un fichier est ainsi constitué :
- d'abord un long mot indiquant de quel type de fichier il s'agit. Pour un programme exécutable c'est la valeur $ 000003F3;
- ensuite un mot long qui est un pointeur sur le nom éventuel du hunk. S'il n'y a pas de nom, ce mot long est nul;
- puis un mot long dont la valeur correspond au nombre de sections hunk constituant le fichier;
- puis une série de mots longs dont chacun est le numéro du hunk à charger. L'ordre de ces mots longs définit donc pour le Dos l'ordre de chargement des hunks;
- enfin une série de mots longs dont chacun est la longueur des hunks dans l'ordre précédemment défini ;
Comme ceci n'est pas clair? Voici un exemple :
00000000 00000003 00000000
00003F3
00000002
00000128
xxxxxxxx
xxxxxxxx
000003F2
00000001 00000009 000000AA 000003E9 00000009 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
yyyyyyyy vvwv ....
nous avons ici un programme exécutable (000003F3) dont le premier hunk n'a pas de nom (00000000) et qui est composé de trois hunks (00000003). Sera chargé d'abord le hunk numéro 0 de longueur $ 09, puis le numéro 2 de longueur $ AA, puis enfin le numéro 1 de longueur $ 128. C'est pourtant simple!
A la suite de tout cela vient normalement le mot long $ 000003E9 qui indique au DOS qu'il arrive sur les données du programme, la longueur est encore une fois indiquée, et l'on a enfin les octets du programme (les mots longs xxxxxxxx de l'exemple ci-dessus).
A la suite des octets au programme et si celui-ci est écrit en code relatif, on trouve l'identificateur $ 000003F2 qui signale la fin du hunk. Sinon, on trouve une table d'offsets qui permettront au DOS de modifier les addresses absolues du programme, suivant l'adresse du chargement. C'est par ce moyen que l'AmigaDos parvient à faire tourner n'importe quel programme n'importe où en mémoire.
On peut également trouver beaucoup d'autres choses, telle une table de débogage, mais cela nous entraînerait trop loin.
PjBBIB OBHP
Enfin derrière le mot long $ 000003F2 (fin d'un hunk), commence, par son identificateur, le deuxième hunk et ainsi de suite jusqu'à la fin du fichier.
Sachant cela, voici comment fonctionne l'installateur de boot : après appel par son nom depuis le CLI ou le SHELL (WorkBench interdit), il demande le nom du programme à transférer dans le boot. Celui- ci est chargé en mémoire, puis on vérifie qu'il s'agit bien d'un fichier exécutable, qu'il est constitué d'un
* Installateur de boot par F MAZUE *
* Ce progranme a été écrit sur DEVPAC 2
* mais ne doit poser aucun
* problème sur un autre assembleur
execbase = 4 AllocMem = -198 FreeMem = -210 01d_0penLi bra ry = -408 CloseLibrary = -414 Read * -42 Write = -48 OutPut * -60 Open * -30 Close = -36 Mode_0ld_f i ie = 1005 IoErr » -132 FindTask = -294 AddPort = -354 RemPort = -360 OpenDevice = -444 CloseDevice * -450 Dolo - -456 Delay - -198
run:
move.l execbase,a6
lea dosname,al
jsr 01d_0penLibrary (a6)
move.l
dO,dosbase
beq
halte
9
STOP si problème
move.l
d0,a6
9
recherche du
jsr
OutPut (a6)
9
canal de la
move.l
d0,CLI_hand.
9
fenêtre CLI
move.l
fecho,d2
9
sortie du texte de demande
jsr
printjnsg
move.l
CLI_handle, dl
9
Lecture du nom du
move.l
Iread tanpon,d2
9
fichier à installer
move.l
200,d3
9
200 chars max
jsr
Read (a6)
lea
read_tampon,aO
move.b
0,-1 (a0,d0)
9
zéro à la fin du nom
move.l
Mode_01d_f i le, d2
9
ouverture du fichier
move.l
read_tampon,dl
jsr
Open (a6)
move.l
dO,fichier handle
seul hunk (il serait possible de traiter un fichier de plusieurs hunks, mais les complications sont grandes pour un intérêt petit). On vérifie aussi que le programme n'est pas trop long (952 octets maxi) et qu'il est bien relogeable. Puis les octets du programme sont extraits et accolés aux octets d'un programme analogue au boot standard. Pour terminer, le Checksum est calculé et cette plage d'octets est écrite dans les secteur O et 1. C'est aussi simple que celà, malgré ce que peut laisser penser la taille du listing...
Frédéric Mazue
beq
dos error
; si pas trouvé ou autre
move.l fichier_handle,dl
; lecture du fichier sur une
move.
1 buffer_fichier,d2
; longueur de 1100 octets max
move.l 1100,d3
; c'est plus que suffisant !
Jsr
Read (a6)
move.
1 fichier_handle,dl
; fermeture immédiate du fichier
jsr
Close (a6)
; pour éviter tout problème
* * ici
est examiné le 1er HUNK du fichier **
lea
buffer_fichier,aO
move.l
(a0),d0
cnp.l
$ 3f3,d0
fichier exécutable ?
Taie
err_fichl
move.l
8 (aO) ,d0
cnp.l
l,d0
une seule section HUNK ?
Bne
err_fich2
move.l
20 (aO) ,d0
move.l
dO,long_fich
cmp.l
$ EE,d0
la longueur acceptable ?
Bhi
err_fich3
lea
prog,al ;
nettoyage du tanpon
move.l
951,dO
clr_loop move.b 0,(al,d0) dbne dO, clr_loop
adda.l 32,aO
move.l long_fich,d0 ; nombre de longs mots
trans_loop:
move.l (a0)+,(al)+ ; isole les octets programme
subq l,d0
bne trans_loop
cmp.l $ 3f2,(aO) ; programme relogeable ?
Bne err fich4
move.l
insert_msg,d2
; demande d'insérer la disquette
jsr
print_msg
; cible
move.l
CLI_handle, dl
move.l
read_tanpon,d2
move.l
200,d3
; attente de la touche return
jsr
Read (a6)
move.l
100,dl
; petite temporisation afin que le DOS
jsr
Delay (a6)
; ait le temps de reconnaître la
; présence de la disquette
jsr
checksum
; calculer le checksum du futur BOOT
move.l execbase,a6
move.l 1024 d0
; 1 Ko'pour les deux secteurs
move.l $ 10002,dl
; mémoire chip et clear
jsr AllocMem(a6)
beq exit
; si pas de mémoire disponible
move.l d0,al
move.l dO,buffer_boot
lea system, aO
move.l 1023,dO
; nombre d'octets-1 à transférer
?repare_boot :
move.b (a0)+, (al) +
dbra dO,prepare_boot
; transféré les octets du progranme-boot
; dans la chip ram reservee à cet effet
rite:
; routine d'écriture des secteurs
suba.l al,al
; oi verture du trackdisk.device
jsr FindTask(a6)
move.l dO,readreply+$ 10
lea readreply, al
jsr AddPort (a6)
lea diskio,al
move.l 0,d0
clr.l dl
lea trddevice,aO
jsr OpenDevice (a6)
lea diskio,al
move.l readreply,14(al)
move.w $ 000E,28(al)
; y a t-il une disquette ?
Move.l execbase,a6
jsr Dolo (a6)
; tester
tst.l 32 (al)
bne no_disk
move.w $ 000F,28 (al)
; est-elle protégée en écriture ?
Jsr Dolo (a6)
tst.l 32 (al)
bne no_write
move.w $ 0003, 28(al)
; commande write
move.l buffer_boot,40(al]
move.l 2*512,36(al)
; longueur : 2 secteurs
move.l 0,44(al)
; à partir de l'octet 0
jsr Dolo (a6)
tst.l dO
; problème ?
Bne hard_error
move.w $ 0004,28(al)
; commande up_date
move.1 system,40 (al)
; pour forcer l'écriture iirmédiate
move.l 2*512,36(al)
; longueur 2 secteurs
move.l 0,44 (al)
; à partir de l'offset 0
jsr Dolo (a6)
; écrire !
Move.l okjnsg,d2
; on annonce fièrement que
jsr printjnsg
; tout c'est bien passé
exit_td:
lea diskio,al
; arrêt immédiat du moteur
move.w $ 0009, 28 (al)
move.l 0,36(al)
move.l execbase,a6
jsr Dolo (a6)
lea
readreply, al
jsr
RemPort (a6)
lea
diskio,al
i
fermeture trackdisk
jsr
CloseDevice (a6)
move.l
buffer boot,al
move.l
1024,dO
jsr
FreeMem (a 6)
exit:
9
on ferme tout
move.l
execbase,a6
move.l
dosbase,al
jsr
CloseLibrary (a 6)
halte:
rts
9
et on s'en va
dos error:
9
traitement des erreurs DOS
jsr
IoErr (a6)
pea
exit
9
adresse de retour sur la pile
onp. 1
202,dO
beq
error_l
cmp.l
204,dO
beq
error_2
cmp.l
205,dO
beq
error_3
cmp. 1
210,dO
beq
error_4
cmp.l
212,dO
beq
error_5
cmp.l
213,dO
beq
error_6
cmp.l
218,dO
beq
error_7
cmp.l
224,dO
beq
error_8
cmp.l
225,dO
beq
error_9
cmp.l
226,dO
beq
error_10
move.
1 error_?_msg,d2
bra
printjnsg
error_‘
L:
move.
1 error_l jnsg, d2
bra
printjnsg
error_
2:
move.
1 error_2jnsg,d2
bra
printjnsg
error_
3:
move.
1 error_3jnsg,d2
bra
printjnsg
error_
4:
move.
1 error_4jnsg,d2
bra
printjnsg
error_
5:
move.l error_5jnsg,d2
bra
printjnsg
error_7: move.l error_7_msg,d2 bra • print_msg
error_8: move.l error_8_msg,d2 bra printjmsg
error_9: move.1 error_9_msg,d2 bra printjmsg
errorJLO: move.l error_10_msg,d2 - bra print_msg
err_fichl: ; traitement des erreurs fichiers
pea exit
move.l err_fichl_msg,d2 bra printjmsg
err_fich2: pea exit
move.l err_fich2_msg,d2 bra print_msg
err_fich3: pea exit
move.l err_fich3_msg,d2 bra print_msg
err_fich4: pea exit
move.l err_fich4_msg,d2 bra print_msg
no_disk: ; traitement des erreurs disquette
pea exitjcd move.l no_disk_msg,d2 bra printjmsg
no_write: pea exitjtd move.l no_writejnsg,d2 bra prihtjosg
hard_error: pea exitjcd move.l hardjerrorjasg,d2 bra printjmsg
printjnsg: ; routine d'écriture à l'écran
move.l d2,a0 clr.l d3
printjnsg_loop : tst.b (a0) + beq printjnsg_2 addq.l l,d3 bra print_msg_loop
print jnsg_2 : move.l dosbase,a6 move.l CLI_handle,dl jsr Write (a6) rts
; Routine de calcul du checksum ; cf. Documentation trackdisk.device ; pour plus de renseignements
checksum: lea system, aO
lea 4(a0),al
clr.l (al) move.w $ 00ff,dl moveq $ 00,dû checksum_l : add.l (aO)-r,dO bcc. S checksum_2 addq.l l,d0
checksum_2: dbf dl,checksumJL not.l dO move.l dû, (al) rts
buffer_boot: dc.l 0 f ichier_handle: dc.l 0 CLI_handle: dc.l 0 dosbase: dc.l 0 long_fich: dc.l 0
; Réservation de 200 octets ; pour le non du fichier.
; remplacer par blk.b 200 pour K-SEKA readjtampon: dcb.b 200,0 dosname: dc.p 'dos.library',0 even
cible_name: dc.b 'DF0: ', 0 even
echo:
dc. b $ 0c,$ 9b,' 1B',$ 9b, '1C' , • *** INSTALLEUR DE BOOT V 1.0 par
F. MA2UE *'**'*
dc. b $ 0A, $ 0A, 'Veuillez donner le nom du fichier à transformer'
dc. b ' en BOOT', $ 0A, ' en précisant'
dc. b $ 9b,'3;33;40m',' correctement ',$ 9b,'0;31;40m'
dc. b "le chemin d'accès",$ 0A,$ ÛA,'? >
even
; Erreurs DOS error_l_msg:
dc. b $ QA,'erreur DOS 202: object in use'
dc. b $ 0A, $ 0A, 0 even error_2_msg:
dc. b $ 0A,"le r ertoire mentionné n'existe pas"
dc. b $ QA, $ ÛA, 0
even
error_3_msg:
dc. b $ 0A,'ce fichier est introuvable'
dc. b $ ÛA,'veuillez vérifier le chemin, puis recommencer'
dc. b $ QA, $ 0A, 0
even
error_4_
msg:
dc. b
$ 0A,"c'est n'importe quoi ce fichier !"
Dc.b
$ 0A, $ 0A, 0
even
error_5
_msg:
dc. b
$ 0A,'il faut apprendre à faire la différence'
dc. b
$ 0A 'entre un fichier et un répertoire mon ami ...'
dc. b
$ 0A, $ 0A, 0
even
error_6
_msg:
dc. b
$ 0A,'cette disquette ne me dit rien qui vaille'
dc. b
$ 0A, $ 0A, 0
even
error_7_
msg:
dc. b
$ 0A,'mais ou se trouve donc cette disquette ?'
Dc.b
$ 0A,$ 0£,0
even
error_8_
msg:
dc. b
$ 0A,'ce fichier est protégé en lecture'
dc. b
$ 0A 'et je ne voudrais pas être indiscret'
dc. b
$ 0A, $ 0A, 0
even
error_9_
msg:
dc. b
$ 0A "ceci n'est pas une disquette pour AMIGA !"
Dc.b
$ 0A, $ 0A, 0
even
error_10_msg:
dc. b
$ 0A,'avec une disquette dans le lecteur, ça ira mieux !'
Dc.b
$ 0A, $ 0A, 0
even
error_?_
msg:
dc. b
$ 0A,"une erreur bizarre autant qu'étrange, et dont je"
dc. b
$ 0A,"ne connais pas la cause est survenue ... désolé"
dc. b
$ 0A,$ 0A, 0
even
; Erreurs Installateur
err flchl msg:
dc. b
$ 0A,"ce fichier n'est pas un fichier exécutable"
dc. b
$ 0A,"il est impossible d'en faire un BOOT"
dc. b
$ 0A, $ 0A, 0
even
err_f ich2_msg :
dc. b
$ 0A,"ce fichier comporte plus d'une section HUNK"
dc. b
$ 0A,"il est impossible d'en faire un BOOT"
dc. b
$ 0A, $ 0A, 0
even
err_fich3_msg:
dc. b
$ 0A,"ce fichier comporte plus de 952 octets"
dc. b
$ 0A,"il est donc d'une trop grande pointure"
dc. b
$ 0A,"pour tenir dans le BOOT (!)"
dc. b
$ 0A, $ 0A, 0
even
err fich4 msg:
dc. b
$ 0A,"ce fichier n'est pas écrit totalement"
dc. b
$ 0A,"en code relatif ET NE PEUT DONC PAS"
dc. b
$ 0A,"constituer un programne BOOT susceptible de "
dc. b
"fonctionner"
dc. b
$ 0A,"veuillez reconsidérer le problème"
dc. b
$ 0A,"et modifier votre prograrme en conséquence"
dc. b
$ 0A, $ 0A, 0
even
; Invitation
insert
msg:
dc. b
$ 0A,"insérer disquette-cible en DF0:"
dc. b
$ 0A,"puis appuyez sur [RETURN]"
dc. b
$ 0A, $ 0A, 0
even
; Erreurs trackdisk.device
no_disk_msg:
dc. b
$ 0A,"je VEUX une disquette en DF0:"
dc. b
$ 0A, $ 0A, 0
even
no_write_msg:
dc. b
$ 0A,"??? La disquette cible est protégée en écriture ???"
Dc.b
$ 0A, $ 0A, 0
even
hard_error_msg:
dc. b
$ 0A,"qu'est-ce que c'est que cette *@&!?] disquette !"
Dc.b
$ 0A,"je veux une disquette formatée correctement"
dc. b
$ 0A, $ 0A, 0
even
; Tout
va bien
ok_msg
dc. b
$ 0A,"tout est OK, Au revoir et à bientôt"
dc. b
$ 0A, $ 0A, 0
even
; Buffer de 100 Ko pour le chargement
; du fichier. Utiliser blk.b 1100 pour K-SEKA
buffer
fichier: dcb.b 1100,$ 00
trddevice: dc.b 'trackdisk.device',0
even
diskio
: dcb.l 22,0 ; blk.l 22 pour K-SEKA
readreply: dcb.l 8,0 ; blk.l 8 pour K-SEKA
system: ; afin que le DOS ne perde pas
les pédales
dc. l
$ 444f5300 ; indicatif DOS
dc. l
$ 0 ; place réservée pour le checksum
dc. l
$ 370 ; blockroot
dc. l
$ 41fa0008 ; programme BOOT standard
dc. l
$ 2f086000,$ 322c79, $ 4
dc. l
$ 43fa001c,$ 4eaeffaO,$ 4a806700
dc. l
$ c2040,$ 20680016,$ 70004e75
dc. l
$ 70ff6000,$ fffa 64 6f,$ 732e6c69
dc. l
$ 62726172
dc. w
$ 7900
prog:
dc. w
$ 4e75 ; instruction RTS pour éviter
; tout problème
dcb.l 238,0 ; réserver 952 octets pour le programme
; blk.l 238 pour K-SEKA
El El Eu E3 DbBu
INTENA
Le listing 2 est un exemple de programme écrit en code relogeable (relatif au PC) s'intégrant parfaitement au boot. Il ne fait rien d'autre qu'afficher quelques bandes de couleurs à l'écran et d'attendre que l'on clique le bouton gauche de la souris.
* *** EXEMPLE DE BOOT ****
* ** à utiliser avec l'installateur ***
* Ce prograime est entièrement écrit en CODE REIATIF
* conme TOUT programme à installer dans le boot DOIT L'ETRE
* INSTALLATEUR vérifiera que c'est bien le cas avant de procéder
* à l'installation.
* De plus et en partie pour la même raison, votre prograirme ne devri
* comporter qu'UNE SEULE section HUNK.
* Pour parvenir à ce résultat, il suffit d'écrire votre prograirme
* avec votre assembleur préféré, mais en un seul bloc, c'est à dire
* SANS utiliser les pseudo-instructions CCDE, DATA et BSS
* La longueur maximum autorisée pour le programme est 952 octets
* Pour tout cela INSTALLATEUR veille au grain.
* Veiller à NE PAS transmettre les labels dans le fichier
* lors de l'assemblage (option export de devpac2 par exenple)
* Un dernier mot: votre programme doit obligatoirement
* sauvegarder les registres 68000 pour éviter un crash
* ultérieur du système.
= S9A = $ 96
* $ 180
= $ 80 = $ 84 = $ 88 = $ 8A
DMACON
COLOROO
COP1LC
C0P2LC
COPJMP1
COPJMP2
CIAAPRA=$ BFE001
OpenLibrary » -552 Forbid = -132
Permit * -138
Alloanem = -198 Freemem » -210
StartList « 38
- 4 -2
execbase chip
start: movem.1 move.l move.l move.l jsr lea
move.l
beq
d0-d7 a0-a6,-(sp); execbase,a6 (end-clstart) ,d0; ichip,dl
Alloanem (a6) ;
cladr(pc),a0 d0, (aO)
fin ;
clstart (pc) ,a0 ;
lea
move.l
move.l
subq
cladr (pc), al f (end-clstart) ,d0 l,d0
instruction INDISPENSABLE
pas de parenthèse avec K-SEKA
réserver mémoire pour copperlist
si pas de mémoire disponible alors STOP MAIS dans le cas d'un programme BOOT on peut supprimer cette instruction et économiser ainsi quelques octets car après un reset TOUTE (!) La mémoire est en principe disponible code relatif oblige
clcopy:
move.b
(a0)+, (al) +
dbra
dO, clcopy
jsr
Forbid(a6) ; désactiver le multi-tâche. C'est
; toujours préférable avant d'imposer ; au système une copperlist personnelle
lea
$ DFF000,a5 ; initialisation de
move.w
$ 03A0,DMACON(a5); la copperlist
move.l
cladr (pc),COPlLC(a5)
clr.w
COPJMP1(a5)
move.w
$ 8280,DMACON(a5)
wait:
; bouton souris ?
Btst
6, CIAAPRA
bne
wait
lea
gmame (pc),al ; réactivation de la copperlist
clr.l
dO ; du système avant de quitter
jsr
OpenLibrary (a6)
move.l
d0,a4
move.l
StartList (a4) ,COPlLC (a5)
clr.w
COPJMP1 (a5)
move.w
$ 83E0,DMACON(a5)
jsr
Permit(a6) ; réactivation du multi-tâche
move.l
cladr(pc),al
move.l
(end-clstart) ,d0
jsr
Freemem (a6)
fin:
clr.l
dO
movem. 1
(sp)+,d0-d7 a0-a6; INSTRUCTION INDISPENSABLE
rts
; INSTRUCTION EGALEMENT INDISPENSABLE
cladr:
dc. l 0
gmame:
dc. b "graphies. Library", 0
even
clstart:
dc. w
$ 500F,$ FFFE,COLOROO, $ 0000
dc. w
$ 580F,$ FFFE,COLOROO,$ 060F
dc. w
$ 600F,$ FFFE,COLOROO,$ 070F
dc. w
$ 680F,$ FFFE,COLOROO,$ 080F
dc. w
$ 700F,$ FFFE,COLOROO,$ 090F
dc. w
$ 780F,$ FFFE,COLOROO, $ 0A0F
dc. w
$ 800F,$ FFFE,COLOROO, $ 0B0F
dc. w
$ 880F,$ FFFE,COLOROO,$ 0C0F
dc. w
$ 900F,$ FFFE,COLOROO,$ 0D0F
dc. w
$ 980F,$ FFFE,COLOROO, $ 0E0F
dc. w
$ A00F,$ FFFE,COLOROO,$ 0F0F
dc. w
$ A80F,$ FFFE,COLOROO,$ 0D0F
dc. w
$ B00F,$ FFFE,COLOROO,$ 0C0F
dc. w
$ B80F,$ FFFE,COLOROO,$ 0B0F
dc. w
$ C00F,$ FFFE,COLOROO,$ 0A0F
dc. w
$ C80F,$ FFFE,COLOROO,$ 090F
dc. w
$ D00F,$ FFFE,COLOROO,$ 080F
dc. w
$ D80F,$ FFFE,COLOROO,$ 070F
dc. w
$ E00F,$ FFFE,COLOROO, $ 060F
dc. w
$ E80F,$ FFFE,COLOROO,$ 000E
dc. w
$ F00F,$ FFFE,COLOROO,$ 000D
dc. w
$ F80F,$ FFFE,COLOROO,$ 000C
dc. w
$ FF0F,$ 0000,COLOROO,$ 0000
dc. w
$ FFFF,$ FFFE
end:
IDHEÜD HBHP
ÎMÏÏÏffi
i_r
PROGRAMMATION
Le SinusScroll de Little zeus
Depuis le temps que vous l'attendez, nous vous proposons une explication très facile à comprendre du fonctionnement complet du Blitter avec son application directe dans un merveilleux programme, un SinusScroll entièrement géré par le Blitter.
Ar, rappelez-vous, notre devise est la V "compréhension par l'application", ainsi, si l'utilisation du Blitter ne vous est pas encore parfaitement claire à la suite de ce numéro, elle le sera dès que nous l'illustrerons par la routine. Le programme intégral vous est proposé en trois numéros avec, dès ce mois-ci, une explication générale du Blitter, condition sine qua non pour la compréhension de la routine.
BLITTER, DEFINITION
Le Blitter, ou Block Image Transférer, permet principalement de copier des zones de données, le plus souvent graphiques, en mémoire. Il peut aussi réaliser des décalages de données, des opérations logiques, tracer des lignes et remplir des surfaces à une vitesse très nettement supérieure à celle du 68000. De plus, Blitter et 68000 peuvent travailler simultanément. Ainsi, si l'Amiga apparaît comme un merveilleux outil graphique, c'est en grande partie grâce au Blitter. Vous avez certainement déjà vu ses prouesses dans de beaux scrollings de jeux (je ne parle pas des éditeurs qui font des adaptations d'Atari en se servant uniquement du 68000 pour leur scrollings), dans des démos à vecteurs, etc. Dans la mesure où notre routine utilise le Blitter uniquement pour faire des transferts de données, nous n'étudierons que cette spécificité. Ce qui ne veut pas dire que dans un futur plus ou moins proche, nous lui ferons exécuter, dans le cadre d'une vecteur-démo, quelques tracés de lignes...
LE BLITTER ET LA COPIE DE DONNEES
Nous allons principalement utiliser dans notre routine la copie de données, dans la mesure où elle est base de tous scrolling. Le mode de copie utilisé par le Blitter est assez simple : celui-ci traite trois zones sources nommées A, B et C et les unit suivant une opération logique où en inhibe une ou deux. Le résultat est placé dans une zone cible nommée D. Précisons tout de même que le Blitter ne travaille qu'en CHIP-RAM, c'est-à-dire dans la zone mémoire allant de $ 0 à $ 7FFFF et qu'il ne peut copier plus de 1 28 Ko à la fois (c'est déjà pas si mal).
Le' Blitter travaille indépendemment du 68000 certes, mais pour être lancé, l'utilisateur se sert de ce dernier afin de poker dans les cases mémoire concernant le Blitter. Ainsi, pour être lancé, le Blitter "doit avoir pris connaissance" :
- du mode utilisé, en l'occurence, on choisit le mode "copie de données";
- de (ou des) zone(s) mémoire source(s) et de la zone cible;
- de la liaison logique;
- de paramètres divers très importants concernant la copie des données;
- de la taille des fenêtres que le Blitter devra traiter.
LES ZONES DE DONNEES SOURCE ET CIBLE
L'Amiga offre quatre paires de registres contenant les addresses de base de chacune des zones de données. En pokant ces valeurs, le Blitter sait à partir de quelles addresses il doit travailler. Néanmoins résident plusieurs problèmes : vous n'ignorez pas qu'un Bitplane, s'il est représenté à l'écran en deux dimensions, n'est en mémoire qu'une suite de données uni-dimentionnelle. Vous n'ignorez pas non plus que de manière à ce que l'ordinateur sache, au moment d'afficher ces données à l'écran, à partir de quel octet il doit passer à la ligne suivante, existent des registres en mémoire spécifiant la largeur et la hauteur des Bitplanes. Enfin, si certaines données en fin de lignes sont indésirables, il vous est possible de les "sauter" au moyen de modulos (si ces motions ne vous semblent pas très claires, reportez-vous aux premiers articles de la Tube-lntro). Le Blitter, à quelques petites différences près, traite les zones mémoires de la même manière. Le registre BLTSIZE précise la hauteur et la largeur des "rectangles- mémoire" à traiter et les registres BLTAMOD, BLIBMOD, BLTCMOD et BLTDMOD contiennent respectivement les modulos des quatre zones mémoires A, B, C et D. Le mieux est d'avoir recours à un exemple : imaginons que nous désirions copier une zone A (correspondant à une partie resctangulaire de bitplane) en une zone D (qui serait le bitplane destination).
Voici une zone mémoire :
$ 0 abcdefgh
$ 8 ijklmnop
$ 16 qrstuvwx
Chaque lettre représente d'un octet du bitplane. Imaginons que nous désirions copier la partie du bitplane qui a pour coin supérieur gauche c et pour coin inférieur droit u. Nous devons donc spécifier au Blitter
- que la largeur du rectangle à copier fait deux mots (4 octets);
- que sa hauteur fait trois lignes;
- que son adresse de base est celle qui contient c ($ 2);
- que son modulo est de quatre octets (largeur du bitplane - largeur du rectangle).
PpjHBEIB BBBP
En conclusion, on n'utilise le mode descending que pour copier une zone mémoire source dans une zone mémoire cible la chevauchant en partie et dont l'adresse lui est supérieure.
Ainsi on copie
c
d
e
f
k
1
m
n
s
t
u
V
Nous voulons copier cette partie de bitplane dans un autre plus large :
LES MASQUES
$ 0
A
B
C
D
E
F
G
H
I
J
K
L
$ 8
M
N
0
P
Q
R
S
T
U
V
W
X
$ 16
Y
Z
0
1
2
3
4
5
6
7
8
9
à partir de E. En spécifiant que l'adresse de base de D est celle contenant E ($ 4) et que son modulo fait huit octets, on obtient après avoir activé le Blitter :
$ 0
A
B
C
D
c
d
e
f
I
J
K
L
$ 8
M
N
0
P
k
1
m
n
U
V
W
X
$ 16
Y
Z
0
1
s
t
u
V
6
7
8
9
LE MODE ASCENDING ET LE MODE DESCENDING
Le Blitter permet deux modes de copie, l'un par incrémentation, l'autre par décrémentation. Avant d'entrer dans les détails, il convient d'expliquer le déroulement d'un traftsffeK mémoire effectué par le Blitter. Dès lors que le registre BLTSIZE, celui qui contient les hauteurs et largeurs des rectangles à traiter, est initialisé, le Blitter se met en route. Il est donc important d'accéder à ce registre en dernier. Par défaut, en imaginant que nous désirions copier une zone A et le met en première position D, puis il en fait de même avec le second, le troisième et ainsi de suite jusqu'au dernier. N'oublions pas que le Blitter saute le nombre d'octets spécifiés par le modulo à chaque fin de ligne copiée. Cependant, il peut apparaître un problème si les zones sources et cibles se chevauchent. Trêve d'explications, voici un exemple :
Adresse Données de la source A
Données de la cible D
Résultat après transfert
0
A
2
B
B
A
4
C
C
A
6
D
D
A
8
E
A
Ceci est dû au fait que lorsque le Blitter arrive à l'adresse 2, celle-ci contient A et non plus B, résultat du transfert précédent. Afin d'échapper à ce problème, il suffit de demander au Blitter de partir de l'adresse 8 pour aller jusqu'à 0 plutôt que de partir de 0 pour aller jusqu'à 8, ce qui est fait par défaut. On utilise alors le mode descending. Dans notre programme le mode ascending conviendra parfaitement car notre scrolling se fait vers la gauche,, c'est à dire que les transferts mémoires se feront vers la base. Dans l'exemple suivant et pour la même raison, le mode ascending serait préférable :
Adresse Données de la source A
Données de la cible D
Résultat après transfert
O
E
2
B
B
E
4
C
C
E
6
D
D
E
8
E
E
Le Blitter traite uniquement des mots, c'est déjà pas mal. Mais imaginons que l'image que nous désirons copier soit large de 7 mots et quelques bits. Comment copier ces quelques bits supplémentaires? Heureusement existent deux masques permettant d'inhiber les bits désirés des mots les plus à droite et les plus à gauche de l'image à transférer.
Zone A (source)
Premier mot Dernier mot
1000111100000011 1111111111111OOO
1111111000000000 OOO111111OOO1OOO 1111111111111OOO 0000111011101010
Masque blitter gauche Masque blitter droit
1111111OOOOOOOOO 000000000000011
Zone D (destination, après transfert)
Premier mot Dernier mot
1000111OOOOOOOOO OOOOOOOOOOOOOOOO 1111111OOOOOOOOO OOOOOOOOOOOOOOOO 1111111OOOOOOOOO OOOOOOOOOOOOOO1o
Seuls sont copiés les bits activés dans les masques blitter.
Remarquons que lorsque le rectangle mémoire à copier ne fait qu'un mot de large, alors il s'effectue un "et logique" entre les deux masques, autrement dit, seuls sont conservés les bits étant activés par les deux masques à la fois. Rappelez-vous bien ceci car nous y ferons largement appel dans notre SinusScroll.
En ce qui concerne les opérations logiques entre les différentes zones sources, le plus simple sera d'en voir directement une application dans le prochain numéro.
Nous avons nommé un certain nombre de registres, en voici la liste avec leur utilisation.
BLTCONO
Bit N ° Fonction
1 5 Valeur de décalage des données la source A
1 4 (nous n'en avons pas parlé)
1 3 Cette valeur est exprimée sur 4 bits
1 2
1 1 Active le canal DMA de A
1 O Active le canal DMA de B
09 Active le canal DMA de C
08 Active le canal DMA de D
07 à 00 utiles aux opérations logiques
que nous verrons prochainement
BLTCON 1
Bit N °
Fonction
1 5
14 1 3 1 2
1 1 à 05
4
3
o
Valeur de décalage des données de la source B
(nous n'en avons pas parlé).
Cette valeur est exprimée sur 4 bits
Inutilisées
Bits servant au remplissage de surfaces (nous n'en avons pas parlé)
1
0
Mettre à 1 pour le mode descending Mettre à O pour la copie de données
Pour utiliser le Blitter, les 4 canaux DMA le concernant (un pour chaque zone A, B, C et D) doivent être activés (registre BLTCONO) et le bit 6 du registre DMACON doit être mis à 1.
BLTCPTH
BLTCPTL
Ces deux registres contiennent l'adresse de la zone source C
BLTBPTH
BLTBPTL
idem pour B
BLTAPTH
BLTAPTL
idem pour A
BLTDPTH
BLTDPTL
idem pour D
BLTCMOD
Valeur du modulo de C
BLIBMOD
idem pour B
BLTAMOD
idem pour A
BLTDMOD
idem pour D
Enfin, le dernier registre à poker, BLTSIZE. Rappelons que dès lors que celui-ci a été poké, le Blitter démarre.
jnnna bbhb
BLTSIZE
- les bits 1 5 è 06 contiennent la hauteur du rectangle en nombre de mots. Des valeurs comprises entre 0 et 102 3 sont donc possibles, 0 sélectionnant la hauteur maximale 1024 (une hauteur nulle est interdite);
- les bits 05 à 00 contiennent la largeur du rectangle en nombre de mots. Des valeurs comprises entre 0 et 6 3 sont donc possibles, 0 sélectionnant la largeur maximale 64 (une largeur nulle est possible). Rappel : quelque soit la résolution choisie, un mot contient 1 6 pixels. La largeur maximale est donc de 1 6 ? 64 = 1 024 pixels.
Vous avez maintenant suffisamment de matière pour aborder le SinusScroll dès le mois prochain. Si quelques notions vous paraissent encore un peu floues, sachez que tout s'éclaircira en passant à l'application même. Sur ce, je vous quitte et vous donne rendez-vous dans le prochain numéro.
Little Zeus
NDLR : Rappelons-le une fois de plus, une série d'articles sur te Blitter démarre dans le prochain numéro, au terme de laquelle vous saurez tout sur ce merveilleux co-processeur.
SCROLLTEXT VERTICAL
Après le scrolltext horizontal de la tube- Intro, voici son petit frère (presque) jumeau, mais dans l'autre sens...
- e programme suivant met en effet en œuvre L un scrolling de texte vertical réalisé grâce au blitter et à la graphies.library (pour écrire les caractères à l'écran). Il n'est pas bien compliqué à comprendre ni à mettre en œuvre dans vos propres démos et ne sera donc pas expliqué plus avant. Si malgré tout vous aviez besoin d'en savoir plus, n'hésitez pas à écrire au journal (NDLR : et reportez- vous aux prochains articles de Little Zeus Cie et Fmazue Corporation pour tout savoir sur le scrolling par le Blitter).
Bernard Saratt
OPT o+,w-
; exec.library ExecBase EQU 4 Forbid EQU -132 Permit EQU -138 AllocMem EQU -198 FreeMem EQU -210 OpenLibEQU -408 CloseLib EQU -414
; graphies.library Text EQU -60 InitRastport EQU -198 Movç EQU -240 InitBitmap EQU -390
; hardware
, include "Hardware.Inc"
,* Voir la Bible de l'Amiga pour connaître la valeur ; des registres...
sectionComRev, C0DE_C ; Assembler en CHIP-RAM please !
Start: « 52-
move.l (ExecBase).w, a6 lea Custcm,a5
jsr Forbid (a6)
move.l 40*220,dO move.l $ 10002,dl jsr AllocMem (a6) move.l dO,Planel beq Exit
lea CLPlanes(pc),a 0 move.w dO,6(a0) swap dO
move.w d0,2(a0)
lea CLColorsl(pc),aO lea CLEnd(pc),al move.w (diwsv*$ 100)+$ 0f,d0 move.w ((diwev-16)*$ 100)+$ 0f,dl moveq $ 0000,d2 moveq 15,d3 Dégradé :
move.w dO, (aO) + move.w $ fffe, (a0) + move.w COl£)R01,(aO)+ move.w d2, (aO) + move.w d2,-(al) move.w CODDR01,-(al) move.w $ fffe,-(al) move.w dl,-(al) addi.w $ 0100,dO subi.w $ 0100,dl addi.w $ 0111,d2 dbra d3,Dégradé Prout :
lea GfxName(pc),al jsr Q?enLib(a6)
liaeiciil ????
Imigri
move.l dO,GfxBase
beq. S FreePlane
move.l d0,a6
lea Bitmap(pc),aO
moveq 1, dO
move.l 320,dl
move.l 200,d2
jsr InitBitmap(a6)
lea Rastport (pc), al
jsr InitRastport (a6)
move. 1 Bitmap, r_bitmap
move.1 $ 32(a 6),OldCopper
move.l NewCopper,$ 32(a6)
bsr.s Main
move.l (ExecBase).w, a6
move.l GfxBase (pc),al
move.l OldCopper,$ 32(al)
jsr CloseLib(a6)
FreePlane:
move.l Planel(pc),al
move.l 40*220,dO
jsr FreeMem(a6)
Exit:
jsr Permit (a6)
moveq 0,d0
rts
Main:
moveq 0,d5 ; conpteur scrolling
moveq 0, d4 ; conpteur pause
Vsync:
arp.b diwev, VHPOSR(a5)
bne. S Vsync
Halte:
cmplb $ 37,$ bfec01 ;
Alt-gauche ?
Beq. S Halte
or.w d4,d4
bne Pause
Scroll:
move.w $ 8400,DMACCN (a5) ; bltpri ON
move.l Planel(pc),a0
move.l -l,BLTAFWM(a5) ; masks
clr.l BLTAMCO (a5)
modulos
move.l $ 09f00000,BLTCONO(a5)
conO et conl
move.l aO,BLTDPTH(a5) ; dest
lea 40(a0),a0
move.l aO,BLTAPTH(a5) ; source
move.w *(219*64)+20,BLTSIZE(a5)
Go, blitter !
Move.w $ 0400,DMACON (a5) ; bltpri OFF
addq.w *l,d5
and.w 7,d5 ; 8 lignes scrollées ?
Bne PasEncore
Write:
move.1 Message(pc),a4
move.b (a4)+,d0
beq. S Vide
subq.b l,d0
beq.s Gauche
subq.b l,d0
beq.s Centre
subq.b l,d0
beq.s Droite
subq.b l,d0
beq.s Pause
bra.s Vide
Gauche:
moveq 39,dl ? 40 chars max
moveq -1, d7
Gauchel:
addq.l l,d7
tst.b (a4) +
dbeq dl,Gauchel
moveq 0,d6
bra. S Ecrit
Centre:
moveq 39,dl ; 40 chars max
moveq -1,d7
Centrel:
addq.l l,d7
tst.b (a4) +
dbeq dl,Centrel
moveq 40,d6
sub.l d7,d6
lsl.w 2,d6
bra.s Ecrit
Droite:
moveq 39,dl ; 40 chars max
moveq 41,d6
moveq -1,d7
Droitel:
addq.l l,d7 subq.l l,d6 tst.b (a4) + dbeq dl,Droitel lsl.w 3,d6 bra.s Ecrit Pause:
addq.b l,d4 bne.s PasEncore bra.s Asuivre ; d6=pos, d7=len Ecrit :
lea Rastport (pc), al move.l d6,d0 move.l 208,dl jsr Move (a6)
lea Rastport (pc), al move.l Message(pc) ,a0 addq.l l,a0 move.l d7,d0 jsr Text (a6)
Vide:
anpa.l MessEnd,a4 bne. S Asuivre lea MessTxt(pc),a4 Asuivre:
move.l a4,Message PasEncore:
btst 6,CIAA_PRA bne Vsync rts
bouton gauche ?
. ************************************
GfxBase: dc.l 0
OldCopper: dc.l 0
Bitmap: dcb.w 4,0
Planel: dc.l 0
Rastport: dc.l 0
rjoitmap: dcb.l 26,0
Message: dc.l MessTxt
GfxName: dc.b "graphies.library",0,0
• ************************************ MessTxt:
dc. b 2,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 1,
dc. b 0,
dc. b 1,
dc. b 1,
dc. b 2,
dc. b 3,
dc. l 0,
dc. b 4
dc. b 2,
dc. b 2,
dc. b 2,
dc. b 0,
dc. l 0,
MessEnd:
EQU * even
"Salut tout le monde !",0,0,0
"Ben voilà un petit scrolling qu'il est",0
"sympathique, non ?",0,0
"Bon, évidemment, il est vertical et",0
"utilise des fonctions de la graphies",0
"library - Move() et Text() pour être",0
"précis.",0,0
"Mais ce système à des avantages :",0 "- on peut écrire tous les caractères",0 " qu'on veut. La preuve : fié'(*ôl !",0 "- il évite d'avoir à se faire chier â",0 " dessiner une fonte... C'est toujours",0 " ça de gagné.",0,0 0,0, 4,0,0,0,0
"Et en plus, il est paramétrable :",0,0 "Aligné à gauche",0,0 "Centré",0,0 "Aligné à droite",0,0 0
"Cliquez le bouton gauche pour terminer",0,0 "ou",0,0
"appuyez sur 'Alt-gauche' pour pauser",0 0,0 0,0,0
diwsh EQU 129
diwsv EQU 41
diweh EQU diwsh+(320-256)
diwev EQU diwsv+200
STRTDIWEQU (diwsv*$ 100) +diwsh STOPDIW EQU (diwev*$ 100) +diweh
NewCopper:
dc. w DIWSTRT,STRTDIW, DIWSTOP,STOPDIW
dc. w DDFSTRT, $ 0038, DDFSTOP, $ 00D0
dc. w BPLCCN0,$ 1000
dc. w BPLCON1,$ 0000,BPI£ON2,$ 0000
dc. w BPL1MDD, $ 0000, BPL2MDD, $ 0000 CLP lânôss
dc. w BPL1PTH, $ 0000, BPL1PTL, $ 0000 CLSprite:
dc. w SPR0PTH, $ 0000, SPR0PTL,$ 0000
CLColors: dc.w COIDR00,$ 0000 CLColorsl: dcb.w 32*4,0
CIEnd: dc.l -2
END
N
VIDEO
Les formats
VIDEO
N° 2
La prise péritel
CAMESCOPE
MAGNETOSCOPE
T. V.
OBSERVATIONS
VHS ou VHSC
VHS
Standard
Ok
8mm
8mm
Pal
Ok
8mm
VHS
Standard
Transcode
SVHS ou SVHS-CS
VHS
YC
Fabuleux
SVHS ou SVHS-C
SVHS
Standard
comme VHS
SVHS ou SVHS-C
VHS
Standard
comme VHS
8 Hi-Band
VHS
Standard
comme 8 mm
8 Hi-Band
SVHS
Standard
comme 8 mm
8 Hi-Band
SVHS
YC
Fabuleux
8 Hi-Band
“8 Hi-Band"
YC
PrEvu
Copie VHS VHS : horrible. Copie 8mm 8mm : moyen. Copie SVHS SVHS ou 8 Hi-BandÆVHS : fabuleux.
1 - Sortie AUDIO (D)roite.
13 - Masse ROUGE.
14 - Masse commande à
distance.
15 - Entrée composante
ROUGE.
16 - Entrée commutation
RAPIDE.
17 - Masse VIDEO composite.
18 - Masse commutation
générale.
19 - Sortie VIDEO composite.
20 - Entrée VIDEO composite.
21 -*
2 - EntrÇe AUDIO (D)roite.
3 - Sortie AUDIO (G)auche.
4 - Masse commune aux deux
AUDIO.
5 - Masse BLEUE.
6 - Entrée AUDIO (G)auche.
7 - Entrée composante BLEUE.
8 - Entrée commutation LENTE.
9 - Masse VERTE.
10 - Horloge (rarement
connectée).
11 - Entrée composante VERTE
12 - Commande à distance
* La fiche 21 sert de masse générale, c'est le blindage de la prise-.
Les résolutions
N° 1
AMIGA
i
TEL
Mode
Résolution
Nombre de couleurs
Basse résolution
320 x 256 pixels
2 à 32
Moyenne résolution
640 x 256 pixels
2 à 16
Haute résolution
640x512 pixels
2 à 16
Interlace
320 x 512 pixels
2 à 32
Extra Half Bright
64
Hold And Modify
4096
Les modes Interface, Extra Half Bright et Hold And Modify
(HAM) ne s'appliquent qu'au mode basse résolution (Low-Res).
La résolution maximale disponible est donc de 320 x 512 pixels
avec 4 096 couleurs.
1
1. Basse ¦
2. N
loye
nne,
3. Inl
erlac
;e, 4
Haute
i
2
3
4
4
mm,
mmm
Téléchargement à double sens. Stockage sur réseau TELETEL.
Boites aux lettres binaires. Dialogue en intelligence artificielle. News, freeware.
Compatibles
Systèmes
PC
UNIX
SCHAKOEl
s * & &
VIDEO
La prise péritel
N° 1
VIDEO Les Formats N° 2
La prise Péritel (périphérique téléviseur) conçue par des techniciens français voit le jour officiellement en 1979. Obligation est faite à tous tes téléviseurs nouvellement fabriqués d’en être équipés. Remodelée en 1981, elle devient une norme européenne internationale.
La prise péritel a été conçue de façon à pouvoir recevoir des signaux d'un maximum de périphérique. C'est ainsi qu’il est possible de lui connecter: des consoles de jeux, des microordinateurs, des camescopes et magnétoscopes, des décodeurs (Canal + , Antiope...), des transcodeurs (PAL SECAM SECAM PAL, fibre optique, télévision par cable...).
Les prises péritel sont équipées de 21 fiches (Voir tableau).
Attention: après presque dix ans de commercialisation, il existe encore des fabricants de prises péritel qui ne savent pas encore ce que signifie le mot norme. Parfois, le son n’est pas connecté ou encore les masses de commutations par exemple. Ces prises sont le plus souvent fabriquées hors des frontières européennes.
COMMODORE REVUE
Le vidéaste a le choix entre divers formats pour la réalisation de ses œuvres. Nous passerons rapidement sur les formats 1 et 3 4 de pouce qui sont réservés par leurs prix aux pros de la vidéo.
Le plus répandu en France est le VHS et le VHS-C surtout parce que les fabricants ont adaptés les camescopes et scopes l’utilisant au standard Sécam. La finesse de l’image est bonne mais le son généralement moyen. Par contre, le parc de scope de salon installé Etant énorme en ce format, il suffit de filmer puis de visionner son œuvre sur celui-ci. Conscient des imperfections, les fabricants viennent âe créer le SVHS qui sépare les signaux chrominance et luminance (Y & C) donnant une image nettement améliorée et le son stéréo. Attention, toute la chaîne est à refaire: il faut un scope de salon en SVHS et un téléviseur munit d’une prise YC.
L'autre grand format est le 8 qui donne une image meilleure que le VHS. Le matériel est le plus souvent en pal et en plus la bande ne peut être mise dans le scope de salon vhs que vous possédez sûrement. Il existe quelques rares scopes de salon 8 et aucune cassette de film préenregistrée dans les vidéo-clubs. Le 8 a quand même un grand succès en France en raison de ses qualités d’image.
Le 8 hi-band est la réplique du 8 au SVHS, utilise aussi le principe YC... et a les mêmes avantages et les mêmes inconvénients.
A très court terme, il semble évident que seuls resterons sur le marche le Hi-Band & le SVHS et comme les scopes utilisant ce format savent aussi relire les anciens formats, il est préférable d’investir actuellement dans ce matériel. Ce qui est important c’est qu’en vidéo, on est amené souvent a faire des copies et que la perte au cours de celle-ci est minime avec ces nouveaux formats.
COMMODORE REVUE
K
DOMPRI
Procurez-vous les
DISQUETTES COMREV
Icônes
Workbench
Son
Animation
Jeu de Rôles
Graphisme
Utilitaire
Disponibles auprès de Commodore Revue, 1 bis, rue de Paradis, 75010 Paris (voir page 76).
AMIGA Les résolutions N° 1
L’Amiga autorise plusieurs modes de représentation des données graphiques, depuis la taille de l’image visible à l’écran jusqu’au nombre de couleurs pouvant être affichées simultanément.
Plus la résolution est élevée (nombre de points par ligne x nombre de lignes), plus fin est le dessin. De même, plus le nombre de couleurs est élevé, meilleur est le rendu de l’image.
On appelle « pixel » (accronyme anglais de picture element) chaque point de l’écran formant l’image.
INTERLACE
Le mode Interlace permet de doubler le nombre de lignes affichées verticalement en basse résolution. Ce mode présente cependant l’inconvénient certain de provoquer un scintillement de l’image, celle-ci . N'étant plus affichée à la fréquence de 50 images par seconde (50 Hz) mais de 50 demi-images par seconde (d’un point de vue technique, l’Amiga affiche d’abord les lignes impaires, puis les lignes paires, le passage d’une demi-image à l’autre étant visible à l'œil nu). Pour remédier à ce problème, il convient de s’équiper d’une carte RickerFixer et d’un moniteur multi-synchrone ou à haute rémanence.
OVERSCAN
L’overscan est une technique permettant «« d’agrandir » l’image visible à l’écran en supprimant son bord - qui devient donc disponible aux données graphiques. L'overscan permet des résolutions de 352 x 290 en basse résolution, 704 x 290 en moyenne résolution et 704 x 580 en haute résolution, les modes Extra Half Bright, HAM et Interlace étant toujours disponibles.
Ight:bold;"> Workbench Son
Animation
Jeu de Rôles
Graphisme
Utilitaire
Disponibles auprès de Commodore Revue, 1 bis, rue de Paradis, 75010 Paris (voir page 76).
AMIGA Les résolutions N° 1
L’Amiga autorise plusieurs modes de représentation des données graphiques, depuis la taille de l’image visible à l’écran jusqu’au nombre de couleurs pouvant être affichées simultanément.
Plus la résolution est élevée (nombre de points par ligne x nombre de lignes), plus fin est le dessin. De même, plus le nombre de couleurs est élevé, meilleur est le rendu de l’image.
On appelle « pixel » (accronyme anglais de picture element) chaque point de l’écran formant l’image.
INTERLACE
Le mode Interlace permet de doubler le nombre de lignes affichées verticalement en basse résolution. Ce mode présente cependant l’inconvénient certain de provoquer un scintillement de l’image, celle-ci . N'étant plus affichée à la fréquence de 50 images par seconde (50 Hz) mais de 50 demi-images par seconde (d’un point de vue technique, l’Amiga affiche d’abord les lignes impaires, puis les lignes paires, le passage d’une demi-image à l’autre étant visible à l'œil nu). Pour remédier à ce problème, il convient de s’équiper d’une carte RickerFixer et d’un moniteur multi-synchrone ou à haute rémanence.
OVERSCAN
L’overscan est une technique permettant «« d’agrandir » l’image visible à l’écran en supprimant son bord - qui devient donc disponible aux données graphiques. L'overscan permet des résolutions de 352 x 290 en basse résolution, 704 x 290 en moyenne résolution et 704 x 580 en haute résolution, les modes Extra Half Bright, HAM et Interlace étant toujours disponibles.

Click image to download PDF

AMIGA NEWS TECH numero 09 (02-1990)

Merci pour votre aide à l'agrandissement d'Amigaland.com !


Thanks for you help to extend Amigaland.com !
frdanlenfideelhuitjanoplptroruessvtr

Connexion

Pub+

55.3% 
9.7% 
3.8% 
3.5% 
3.1% 
2.2% 
2.1% 
1.3% 
1% 
0.9% 

Today: 3
Yesterday: 90
This Week: 93
Last Week: 732
This Month: 2019
Last Month: 2867
Total: 77407

Information cookies

Cookies are short reports that are sent and stored on the hard drive of the user's computer through your browser when it connects to a web. Cookies can be used to collect and store user data while connected to provide you the requested services and sometimes tend not to keep. Cookies can be themselves or others.

There are several types of cookies:

  • Technical cookies that facilitate user navigation and use of the various options or services offered by the web as identify the session, allow access to certain areas, facilitate orders, purchases, filling out forms, registration, security, facilitating functionalities (videos, social networks, etc..).
  • Customization cookies that allow users to access services according to their preferences (language, browser, configuration, etc..).
  • Analytical cookies which allow anonymous analysis of the behavior of web users and allow to measure user activity and develop navigation profiles in order to improve the websites.

So when you access our website, in compliance with Article 22 of Law 34/2002 of the Information Society Services, in the analytical cookies treatment, we have requested your consent to their use. All of this is to improve our services. We use Google Analytics to collect anonymous statistical information such as the number of visitors to our site. Cookies added by Google Analytics are governed by the privacy policies of Google Analytics. If you want you can disable cookies from Google Analytics.

However, please note that you can enable or disable cookies by following the instructions of your browser.

Visitors

Visite depuis
03-10-2004
Visite depuis
23-02-2014