 |
Mardi 16 avril 2024 - 17:48 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Comment échanger des données et communiquer entre deux Amiga ? Le plus simple à mettre en oeuvre, avec de simples Amiga, est de copier les fichiers de l'un sur une disquette, puis de lire la disquette sur l'autre. Cette solution a l'avantage de ne nécessiter aucun logiciel ni matériel (à part une ou plusieurs disquettes), mais a l'inconvénient de ne pas être très rapide, et demande des manipulations physiques (changer la disquette de machine).
Si on veut copier des Mo (Méga-Octets) de données de l'un à l'autre, il faudra pas mal de manipulations de disquettes, ce qu'on appelle de façon humoristique "faire du grille-pain", et il sera donc impossible de le faire sans une présence humaine.
A l'opposé, on peut mettre nos deux Amiga en réseau, à l'aide de la carte Ethernet A2065 de Commodore (sauf sur un A500, A600 ou un A1200). On dispose alors d'une connexion très rapide, une liaison Ethernet étant à 10 Mb/s (1,25 Mo/s, soit la vitesse d'un très bon disque dur). L'inconvénient de cette solution est son coût (les deux cartes + le logiciel), et l'installation qui n'est pas triviale.
Heureusement, l'Amiga dispose d'autres entrées/sorties que le lecteur de disquette, en particulier les deux ports de communication : le port série et le port parallèle. On devrait donc pouvoir faire communiquer nos deux Amiga par le biais de l'un ou l'autre de ces ports. Voici le fonctionnement de ces ports, avec leurs avantages et inconvénients :
Dans le cas du port série, les données sont lues ou envoyées bit par bit (en série), tandis que dans le port parallèle les 8 bits de chaque octet sont lus ou envoyés en même temps (en parallèle). L'avantage du port série est que pour une communication minimale, c'est-à-dire utilisant aussi peu de matériel que possible, il suffit de trois conducteurs : la masse (GND), l'émission (TX) et la réception (RX). L'avantage du port parallèle est la rapidité, en principe 8 fois supérieure à la liaison série, avec comme inconvénient un nombre de conducteurs supérieur à 9 (les 8 bits et la masse).
En fait, il faut au minimum 11 conducteurs : la masse, les 8 bits, et (en gros) le signal de sortie "donnée valide" (prêt à émettre) et le "signal d'entrée acquittement" (prêt à recevoir). Ces deux signaux sont nécessaires, car les 8 conducteurs de données sont bidirectionnels, et il faut que le sens de communication soit déterminé (émission ou réception), contrairement au port série où il y a un conducteur pour chaque sens. Dans la pratique, pour faciliter la communication, on utilise plus de conducteurs, que soit avec un modem (surtout s'il est rapide) pour la prise série. ou une imprimante pour la prise parallèle. Ces conducteurs supplémentaires servent à faire transiter des signaux de contrôle additionnels, qui rendent la communication à la fois plus rapide et fiable.
Voyons à présent comment utiliser ces capacités de façon pratique. Grâce à sa conception en "couches" logicielles, le système d'exploitation (AmigaOS) va permettre d'utiliser les ressources matérielles de manière transparente.
C'est-à-dire qu'une fois installé le pilote du matériel, pilote constitué par un périphérique logique et/ou un gestionnaire, toutes les commandes habituelles d'AmigaOS vont être directement exploitables, indépendamment du matériel, par exemple par une requête de fichiers. Un exemple parfait est MultiDos (un logiciel dans le domaine public), qui permet de lire des disquettes au format MS-DOS, en créant un périphérique logique MD0:. MultiDos est constitué d'un handler (MultiDosFileSystem), qui gère le système de fichiers, et d'un périphérique logique (MultiDos.device), qui gère les données brutes sur la disquette ; grâce à quoi on peut manipuler une disquette MS-DOS (avec MD0:) comme une disquette Amiga (avec DF0:). MSH (Fish 38-2) offre les mêmes services, et dispose en plus des sources.
Les solutions
Il existe dans le domaine public au moins trois logiciels de communication qui conviennent : ParNet, DNet et SerNet. ParNet utilise le port parallèle et DNet le port série. ParNet permet à chaque Amiga de voir les disques de l'autre machine de manière transparente, en créant un périphérique logique NET:; DNet permet d'échanger des fichiers, de se parler (chat window) et d'ouvrir un Shell sur l'autre machine (remote shell). SerNet est la version série de ParNet, à utiliser avec DNet.
Pour utiliser ces logiciels, il suffit en gros d'installer quelques fichiers sur le disque système, de relier les deux Amiga par un câble approprié, et c'est prêt. Précisons où on peut trouver ces petites merveilles : ParNet 2.4 sur Fish 400, DNet 2.10.1 (attention, s'appelle parfois 2.20) sur Fish 294, et SerNet n'est pas sur Fish mais sur Aminet.
ParNet
Commençons par explorer ParNet, une oeuvre concoctée par la Software Distillery, à qui l'on doit beaucoup d'autres utilitaires. Grâce à ParNet, nous pouvons ici, au club ATP, mettre en commun nos disques durs, entre l'Amiga 3000/16 (disque de 52 Mo) et l'Amiga 3000/Unix (disque de 100 Mo côté Amiga + SyQuest de 88 Mo). On peut ainsi se passer de copier toutes les grosses applications (par exemple Deluxe Paint et Excellence!) sur les deux machines, et économiser bien de la place.
L'installation logicielle de ParNet est plutôt simple : sur chaque machine, on place parnet.device dans Devs:, netpnet-server dans C: et netpnet-handler dans L:, ainsi qu'une entrée NET: dans la liste de montage Mountlist. Cette entrée diffère par le numéro d'unité, 0 sur l'un des Amiga et 1 sur l'autre.
La documentation explique le câble à utiliser, qui diffère d'un câble parallèle classique, dont certaines liaisons doivent être supprimées. Il faut relier la masse, les 8 bits de données, les signaux BUSY, P(aper)OUT, SEL(ect), ACK(nowledge), soit plus que les onze liaisons mentionnées au plus haut. La documentation précise bien de tester plutôt deux fois qu'une si le câble est bien construit comme il est spécifié (sinon, cela peut éventuellement endommager l'Amiga). Ce n'est pas très difficile à faire (je n'avais jamais soudé), mais dans le doute, il vaut mieux s'adresser à un ami compétent ou à un magasin d'électronique.
Une fois que tout est correctement installé, il faut lancer NetPNet-Server (unité 0 ou 1 à spécifier) et monter NET:. Le plus simple est de faire un petit script, que l'on peut lancer depuis le Workbench en double-cliquant sur une icône. On voit apparaître sur le Workbench une nouvelle icône appelée "Network". Au départ, en double-cliquant sur cette icône, on ne voit rien, et en faisant une commande "List NET:" dans une fenêtre Shell on obtient un répertoire vide. Pour que les disques (ou périphériques logiques) de l'autre machine soient visibles, il faut y accéder une première fois, par exemple en faisant un commande "List" ou un "CD". Pour voir le RAM: de l'autre, il faut faire "List NET:RAM", pour Work:, il faut faire "List Net: Work", de même pour chaque périphérique logique. Là aussi, le script de lancement peut s'en charger.
Chaque fois qu'un premier accès est fait sur un disque (par exemple RAM:), il apparaît dans NET: une icône correspondante (par exemple RAM.info), même si elle n'existe pas sur le disque. Ceci est conçu pour que le volume soit visible depuis le Workbench, et on a intérêt à laisser, au lieu de l'image par défaut, une icône à son goût dans la racine du volume, sous le nom "node.rinfo". Cette opération est à faire une fois pour toutes, seul le disque RAM: perd ce fichier à chaque redémarrage.
De manière générale, pour accéder au fichier "Dev:a/b/c" de l'autre, on utilise "NET:Dev/a/b/c". Par exemple, pour accéder au fichier "Work:Readme" on tape "NET:Work/Readme". ParNet n'est malheureusement pas parfait (il y a un bogue dans le handler), et parfois, après un "cd NET:DH0/a/b", un Dir a pour résultat "Object Not Found". Il existe pour cela un correctif, pas tout à fait propre car, n'ayant pas les sources, l'auteur a modifié une fonction d'Exec. Ne m'étant pas servi de ce correctif jusqu'à présent, je ne peux pas me prononcer sur son efficacité ni sur son innocuité.
Il existe plusieurs utilitaires pour exploiter ou étendre les possibilités de ParNet. Tout d'abord NetStat (inclu dans ParNet), qui donne le débit du réseau dans chaque sens, le débit de pointe, et en plus affiche graphiquement le tout. Au club ATP, on obtient un débit moyen de 45 ko/s sur un gros transfert (fichier de 500 ko). Ce débit est obtenu en utilisant une version améliorée et compilée pour 68020, sinon avec le parnet.device original, on atteint plutôt 30 ko/s (entre deux A500 le débit ne doit pas être aussi élevé). Ces chiffres sont à comparer avec les 10 ko/s que fait une disquette en moyenne.
Ensuite, il y a NetMount (Fish 863), destiné à faciliter le montage des périphériques logiques de l'autre machine. On précise les périphériques logiques à monter dans les types d'outils de l'icône, et le disque système. Il peut créer des assignations pratiques, comme NetSys: pour le disque système de l'autre, NetC: pour le répertoire C: correspondant, et ainsi de suite.
Enfin, NetUtils (DP) permet d'ouvrir une fenêtre de dialogue (chat window), et d'envoyer une commande à exécuter sur l'autre machine. On peut mentionner aussi la possibilité pour ParNet de se connecter à un CDTV, et de se servir de la souris et du clavier de l'Amiga comme s'ils étaient branchés sur le CDTV.
DNet
DNet a été écrit par Matt Dillon, un des auteurs les plus productifs et imaginatifs dans le domaine public Amiga, à qui l'on doit par exemple Csh, DICE, DME, DMouse, UUCP, et même ParNet. DNet est plus complet que ParNet, car il permet non seulement d'échanger des fichiers entre deux Amiga, mais en plus d'ouvrir un Shell qui va tourner sur l'autre machine (alors que la fenêtre du Shell sera sur la nôtre), et enfin d'avoir une fenêtre dans laquelle on peut se parler d'un Amiga à l'autre (chat window).
En plus, une caractéristique très intéressante de DNet est qu'il est prévu pour fonctionner également entre un Amiga et une machine Unix. De surcroît, comme il s'agit d'une communication par le port série, on peut connecter ainsi deux machines distantes, par l'intermédiaire d'un modem. On peut ainsi créer une sorte de serveur, qui pourra être appelé par un autre Amiga utilisant le protocole DNet.
DNet est nettement plus compliqué à installer que ParNet. Il se compose d'une douzaine d'exécutables, et fonctionne selon le mode client/serveur. Il y a pour chaque application, d'un côté le serveur, de l'autre le client, qui fait des demandes au serveur, et ce dernier lui renvoie les informations demandées. Il faut installer tous les exécutables clients dans un répertoire qui doit être dans le "path" du Shell depuis lequel on lance la commande principale "DNet". Il faut également préciser dans le fichier s:DNet.Servers l'endroit où se trouvent les serveurs et quel sera leur répertoire courant. Le câble de liaison est un câble Null Modem, auquel, comme pour ParNet, il manque certaines connexions (si on utilise un modem, on se sert d'un câble modem classique).
Les applications de DNet :
GetFiles/PutFiles : effectue les transferts de fichiers. Par exemple, la commande "getfiles -dRam: Work:graphisme/toto.ilbm Wb2_x:readme" va ramener dans notre disque "Ram:" les deux fichiers "toto.ilbm" et "readme" de l'autre machine. Par cette commande, on peut aussi ramener une arborescence entière. La commande putfiles effectue les transferts dans le sens inverse, vers l'autre machine. Pendant le transfert, la commande affiche le fichier en cours et la quantité déjà copiée. Les serveurs associés sont respectivement SGCopy et SCopy.
FTerm : ouvre une fenêtre qui permet d'écrire à l'autre Amiga. Ce que l'on écrit dans la fenêtre s'affiche également sur une fenêtre de l'autre machine. Pour parler à deux, chacun ouvre sa fenêtre FTerm de son côté, et on se retrouve avec deux fenêtres de chaque côté : une où l'on écrit, l'autre où on lit. Le serveur associé s'appelle STerm.
CliTerm : ouvre une fenêtre CLI/Shell dont le processus est sur l'autre Amiga. C'est extrêmement pratique : dans le cas d'une communication par modem, c'est comme si l'on était installé devant l'écran de l'autre machine (en mode texte), bien qu'elle puisse être à plusieurs milliers de km ! Bien sûr, si on lance un programme qui ouvre une fenêtre, celle-ci s'affichera sur l'autre machine, et on peut même se retrouver bloqué : si on a le malheur de taper "DPaint" ou "PPMore", on ne pourra rien faire pour quitter l'application (il faut la souris), et comme on n'aura pas "runné" la commande, le Shell ne rendra pas la main.
Le même problème existe avec une faute de frappe : si on tape "List wirk:" et que ce volume n'existe pas, sur l'autre machine va s'afficher la requête système "please insert...". Heureusement, le problème des requêtes système peut être évité en lançant à l'ouverture du Shell la commande "noreq" (incluse dans DNet), qui empêche l'apparition de ceux-ci. Il faut donc faire attention à ne pas taper de commandes qui ouvrent une requête de fichiers ou un écran/fenêtre. Le serveur associé est SCli, et requiert l'utilisation d'un pipe spécial appelé DPIPE:. En fait, le CliTerm est un FTerm modifié, en particulier on peut éditer la ligne de commande, avant qu'elle ne soit envoyée à l'autre machine pour être exécutée.
Il existe également le serveur SPrint, qui permet de se servir de l'imprimante de l'autre machine. La documentation ne s'étend pas sur cette possibilité.
StatONet donne les statistiques d'utilisation du réseau, par exemple le nombre d'octets échangés, les erreurs survenues.
Quand les deux Amiga sont reliés en permanence (par un câble), on utilise la procédure de connexion la plus simple appelée "manuelle". Chacun lance la commande "DNet" avec l'option "-X", obtient la fenêtre de départ de DNet, puis l'un des deux sélectionne le menu "StartDNet". La fenêtre DNet disparaît, et si tout se passe normalement, après quelques secondes apparaît une fenêtre FTerm. A partir de là, comme le protocole DNet est actif, on peut lancer ce que l'on veut plusieurs FTerm, des transferts de fichiers dans les deux sens, un CliTerm. DNet se débrouille pour ne pas mélanger les multiples informations qui circulent sur la liaison, en les envoyant sous forme de paquets de types différents. Pour quitter le protocole, il suffit de lancer la commande "QuitDNet". Elle ferme toutes les applications DNet, même un transfert en cours, et on se retrouve avec la fenêtre DNet originale, qu'il suffit de fermer.
DNet en pratique
J'ai pu tester personnellement les performances de DNet, en reliant mon Amiga à celui de mon voisin qui habitait un étage au-dessus et à côté. En faisant passer le câble par des bouches d'aération pour la sortie, et le long de la façade (sous le lierre pour être discret !), il en fallait 25 m. Une telle longueur nécessite un câble blindé, sous peine de subir des phénomènes de capacité et des parasites ; ce blindage permet d'utiliser par conséquent des vitesses de transmission plus élevées. Plus le câble est long, moins la vitesse pourra être élevée. Il était intéressant pour des raisons de coût que ce soit une liaison série, car j'ai pu me contenter d'un câble Null Modem minimal, à trois conducteurs, assez bon marché (4 FF/m). S'il s'était agi d'une liaison parallèle, elle aurait été sans doute nettement plus performante, mais bien plus chère (et plus casse-pieds à souder :-)).
Normalement, avec un processeur 68000, la vitesse maximum utilisable du port série est de 19 200 bauds, si on veut pouvoir faire du multitâche. Ceci est dû en partie aux faibles performances du serial.device, surtout en Workbench 1.3. Au passage, il est intéressant de préciser qu'à haute vitesse, seule la réception pose un problème, car le port série ne dispose pas d'un tampon mémoire matériel (2 ou 3 octets en général). Par contre, on peut émettre à 115 200 bauds sur un A500 sans problèmes. Grâce au BaudBandit.device (DP), un serial.device très performant par Christian Buchner, nous avons pu établir une liaison fiable à 38 400 bauds entre nos deux A500.
Nous nous arrangions pour laisser nos Amiga allumés assez souvent, et grâce aux transferts de fichiers (environ 3 ko/s), nous pouvions nous laisser des messages, et avoir ainsi une sorte de messagerie élémentaire. Je pouvais même redémarrer à distance l'autre machine, qui au démarrage relançait DNet pour me permettre de me reconnecter ! Une remarque importante : malgré mes efforts, je n'ai pas réussi à ouvrir plus d'une fenêtre CliTerm à la fois, alors qu'il est plus confortable d'avoir au moins deux Shell.
Je n'ai mentionné jusqu'à présent que la connexion "manuelle". Il existe deux autres types de connexions : celle où l'on appelle une autre machine (Dial-Out), et celle où l'on est à l'écoute d'une demande de connexion (Auto-Answer). Ces deux modes sont plutôt conçus pour des liaisons par modem, et pour cela on précise ses besoins dans le fichier de configuration s:DNet.config. Dans le mode Dial-Out, si on n'est pas certain des intentions de la personne que l'on appelle, on peut interdire l'accès en lecture ou en écriture à certains répertoires ou fichiers, pour que certains fichiers restent confidentiels (si l'autre veut faire un GetFiles) ou protégés contre l'écrasement (cas de PutFiles).
Dans le mode Auto-Answer, le fichier s:DNet.config contient en plus des noms d'utilisateurs, et pour chaque nom un mot de passe et des droits associés. Ainsi, lors de la connexion, par défaut on ne peut pas accéder aux fichiers ni ouvrir de CliTerm, il faut pour cela ouvrir un FTerm qui fait appel au serveur SPassWd, qui demande un nom et un mot de passe. Une fois l'utilisateur validé, il obtient les droits spécifiés dans le fichier de configuration. Matt Dillon a même prévu l'utilisation d'un serveur BBS (Bulletin Board System, une messagerie en somme) appelé DBBS, qui n'est pas livré avec DNet.
DNet étant livré avec ses sources, on peut s'y plonger, améliorer son fonctionnement (pourquoi pas), et surtout créer toutes sortes d'applications supplémentaires. Il y a par exemple le dnet.device (inclus dans DNet), qui permet d'ouvrir un remote Shell (CliTerm) avec l'émulateur terminal de son choix (par exemple Vlt, Term), au lieu du FTerm modifié, pour avoir une meilleure émulation ou par exemple un "review buffer". Il suffit de choisir, au lieu du serial.device unit 0, le dnet.device unit 8195, et le tour est joué ! (le nombre 8195 correspond au numéro du serveur SCli, précisé dans s:DNet.servers).
Il y a l'émulateur terminal NiftyTerm (Fish 485), pratique car il est petit (50 ko) et s'ouvre sur le Workbench, et qui par défaut ouvre le dnet.device unit 8195. Il y a également dshterm (DP) qui ouvre une connexion CliTerm dans un Shell déjà existant, ce qui permet d'utiliser un DP comme Console-Buffer, ou de l'ouvrir dans une fenêtre Sphinx: (DP) (ou plus récemment KingCON) qui possède une barre de défilement.
DNet avec Unix
Avec une machine Unix, tout marche comme avec un autre Amiga, sauf qu'on peut ouvrir plusieurs fenêtres Shell, qu'il y a un utilitaire appelé LoadAv, qui indique la charge de la machine Unix, et qu'on peut accéder aux fichiers Unix grâce au périphérique logique NFS:, qui utilise du côté Amiga le Nfs-Handler (inclus dans DNet). A ce sujet, il existe un petit correctif pour les sources de snfs (serveur côté Unix) avec un Sun, sinon on obtient n'importe quoi côté Amiga.
L'installation côté Unix est très facile, il suffit de taper "make" en gros. C'est très pratique, et je m'en sers régulièrement quand je me connecte à mon compte Unix, situé sur un Sun à la fac de Paris-6. J'ouvre un Shell dans lequel je consulte mon courrier électronique, un autre dans lequel j'explore et je ramène les derniers DP Amiga (côté Unix), un troisième pour être à l'aise, et je transfère en plus des fichiers (les derniers DP, miam :-)) avec get/putfiles. Il existe une version de DNet enrichie (pas par Matt Dillon) et numérotée 2.32 (au lieu de 2.10 ou 2.20), qui a besoin de la ixemul.library et du Workbench 2.0, que je n'ai pas testée. La photo d'écran 1 montre un exemple de connexion Amiga/Unix.
Pour relier trois Amiga, on pourrait utiliser DNet entre le premier et le deuxième et ParNet entre le deuxième et le troisième, les accès entre le premier et le troisième étant un peu compliqués. Encore mieux, avec une carte multi-série comme en fabrique Commodore, on peut relier plus de trois Amiga, cela dépend du nombre de ports série supplémentaires apportés par la carte.
SerNet
SerNet est la version série de ParNet, et utilise une liaison DNet. On a donc les mêmes possibilités dans les deux cas, ParNet ayant l'avantage d'une vitesse bien supérieure, et SerNet celui de pouvoir être établi à grande distance par modem. SerNet est composé d'un handler, d'un serveur, d'une entrée dans la liste de montage, et d'une entrée dans s:DNet.Servers.
Il faut d'abord lancer DNet, puis ensuite un "Mount NET:" (ou DNET:, ou ce qu'on veut en fait), et un "List NET:" pour l'activer vraiment. Comme pour ParNet, il y a moyen de se servir de la souris et du clavier d'un Amiga comme s'ils étaient branchés sur l'autre (utilise un serveur appelé SNetKeys).
Autres
Pour échanger une grosse quantité de fichiers entre deux Amiga, on peut aussi faire appel à TwinExpress (sur Aminet), qui utilise une liaison série (un câble Null Modem). TwinExpress est commercial, et j'ai essayé la version démo qu'on peut trouver sur les réseaux. Possibilité très intéressante : ce programme permet aussi de faire des transferts entre un Amiga et un PC, au lieu d'utiliser MultiDos (ou MSH ou CrossDOS) et de faire du "grille-pain".
L'intérêt de ce programme est qu'il permet une liaison a 115 200 bauds (vous avez bien lu !) entre deux A500 de base, soit environ 11 ko/s. Pour cela, il a tendance à couper le multitâche et sans doute les interruptions, car la souris saccade quand un transfert est en cours. On peut comme pour ParNet/SerNet accéder aux disques de l'autre et ramener une arborescence entière.
Conclusion
Le domaine public nous offre des outils fiables, performants et gratuits, faciles à installer dès que l'on connait un peu l'Amiga, et dont peu d'autres micros ont l'équivalent, même payant. À propos de ParNet, il existe une version plus récente que la 2.4, appelée ParBench, qui s'installe très facilement grâce à "l'Installer" de Commodore.
Voilà, j'espère que ce petit tour de la communication vous incitera à connecter vos machines, et pourquoi pas, à créer de nouveaux utilitaires encore plus performants (par exemple, la gestion des nouveaux DosPacket du 2.0 et 3.0).
|
