 |
Vendredi 06 juin 2025 - 12:49 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Certains écosystèmes informatiques ont bien géré cette situation. Par "bien", j'entends que les normes pour les API d'interface réseau ont assez rapidement été adoptées par leurs communautés et gérer par leurs systèmes d'exploitation. Cela a permis à tous les logiciels qui voulaient fournir des solutions impliquant Internet de le faire, sans avoir à se préoccuper de savoir si leurs programmes fonctionneraient sur des interfaces Internet plus récentes ou concurrentes. Quelques exemples évidents du début des années 1990 sont les PC avec Windows via WINSOCK, les ordinateurs Apple avec MacTCP, les ordinateurs Amiga avec AmiTCP, Atari STiNG, et d'autres.
Cette adoption a été vitale pour l'évolution des logiciels de mise en réseau. Avec une seule API viable à écrire, par exemple un navigateur Web, des navigateurs concurrents ont pu être développés, chacun essayant de surpasser les autres en termes de fonctionnalités, ce qui a fait progresser la logithèque. Qu'il s'agisse d'Internet Explorer ou de Netscape, ou d'IBrowse ou d'AWeb, c'est exactement ce qui s'est passé.
C'est cette histoire amusante - ce défilé de technologies - que je vais vous faire découvrir, avant d'amener mon propre avis.
À cette époque, le "port utilisateur" du C64, où les modems série étaient connectés, était considéré comme limité à 2400 bauds. Cette limitation a été surmontée de deux manières différentes.
La première consistait à utiliser la cartouche UART 6551 "SwiftLink" de Creative Micro Designs. Cette cartouche monopolisait le port d'extension de l'ordinateur pour fournir une interface série RS-232 standard dédiée plus rapide, capable d'utiliser des modems plus rapides disponibles pour les PC jusqu'à 38,4 bps.
La modification de l'UP9600 de Danial Dallmann, présentée en 1997, a également permis d'atteindre des vitesses plus élevées. Il s'agissait d'une modification de l'interface série du port utilisateur standard C, qui utilisait des broches supplémentaires pour tirer parti de la fonction de décalage automatique des bits de l'ordinateur. Comme son nom l'indique, il permettait au C64 de communiquer de manière fiable à 9600 bauds. La modification elle-même pouvait être apportée au modem ou à l'ordinateur, et ne nécessitait que le branchement de quelques broches supplémentaires les unes aux autres.
Bien sûr, toute cette variété d'Internet commuté est morte avec la perte de popularité et de disponibilité des comptes shell des FAI.
Nous sommes donc toujours dans les années 1990 et nous avons déjà trois interfaces matérielles pour Internet. Il est donc temps de parler des émulateurs de modem sur PC et des câbles null modem.
Avec certains de mes vieux amis du babillard électronique, nous avons entrepris de connecter mon Commodore 128 à l'une de ces machines à l'aide d'un câble null modem, qui est simplement un câble série permettant à deux ordinateurs de communiquer entre eux. Une extrémité du câble se connectait au port série du PC, tandis que l'autre extrémité se connectait au port utilisateur du C128, après avoir traversé quelques puces de conversion de tension. Le C128 exécutait mon logiciel babillard électronique et attendait que le signal "Carrier Detect" soit activé sur le port série. Pendant ce temps, le PC lançait un programme terminal Linux appelé "minicom" lorsqu'un utilisateur se connectait, ce qui réveillait automatiquement le programme du babillard électronique du C128 et s'annonçait à l'utilisateur. En fait, en se connectant à distance au PC via Telnet, et en se connectant, on utilisait un babillard électronique fonctionnant sur un Commodore 128.
Leif Bloomquist
Ce projet a été suivi par un projet de Jim Brain appelé "TCPSER", qui utilisait également des câbles null modem. Il s'agissait d'un portage de BBS Server sur Linux, avec la même émulation de modem Hayes/C 1670 que BBS Server.
Le dernier de cette catégorie est Strikelink USB, écrit par Alwyz, auteur du populaire programme CCGMS pour le C64. Dans ce cas, le Strikelink est un câble qui connecte l'interface série du port utilisateur Commodore au port USB d'un PC au lieu du port COM standard. Comme les variantes ultérieures du Strikelink, il n'a jamais été produit pour la vente, mais seulement présenté comme un projet pour les utilisateurs intéressés.
Ce type de solution est encore utilisé aujourd'hui. Le Strikelink USB ne remonte en fait qu'à une dizaine d'années. Cependant, la nécessité d'avoir un PC physiquement proche de votre ordinateur Commodore a probablement limité sa popularité globale.
La plus évidente était de continuer à utiliser les mêmes modems que ceux utilisés pour les comptes shell, mais l'une des méthodes les plus étranges qui a eu son heure de gloire était le Palm Ethernet Cradle pour le Palm Pilot. Cette petite station d'accueil était en fait une petite boîte qui prenait les paquets PPoE de son port série RS-232 standard et les envoyait par sa prise Ethernet RJ-45 câblée. Les utilisateurs de vieux ordinateurs devaient ouvrir le boîtier pour brancher un connecteur 9 broches normal, puis utiliser soit la cartouche SwiftLink, soit le câble null modem à tension décalée mentionné plus haut.
En ce qui concerne les logiciels, le système d'exploitation C64/C128 LUNIX, de Daniel Dallman, disposait d'un client SLIP et PPoE, ainsi que de quelques outils Internet de base, tels que les clients Telnet et FTP, et un serveur Web. Un autre client Internet était The Wave, pour le système d'exploitation Wheels, qui comprenait un programme de terminal et un navigateur web.
Les berceaux Ethernet sont peut-être encore utilisés, mais l'accès à Internet par ligne commutée n'est plus vraiment courant. En outre, si certains se souviennent encore de LUNIX, The Wave nécessitait à la fois Wheels OS et un Super processeur, ce qui lui conférait une audience limitée.
La cartouche contient une puce Ethernet Cirrus Logic CS8900a, qui est configurée en mode 8 bits. Des registres sont alors exposés sur la page d'adresse du port d'expansion du C64 pour permettre le transfert de paquets d'octets dans les deux sens.
Le RR-Net a finalement été transformé en une véritable cartouche autonome, entièrement compatible avec le module d'extension RR-Net original. On peut les trouver sous les noms "RR-Net MK3" chez Individual Computers, "TFE" chez Adam Dunkels, et "64NIC" chez go4retro.com.
Une solution de cartouche comme celle-ci présente l'avantage de la vitesse, mais les inconvénients de monopoliser le port cartouche et d'exiger que le C64 exécute une pile TCP/IP complète, avec ses propres tampons mémoire. Une demi-douzaine de logiciels gèrent le RR-Net, dont des terminaux, un navigateur et des outils de transfert PC, le plus impressionnant étant Contiki d'Adam Dunkels. Contiki est un système d'exploitation à interface graphique doté d'une pile TCP/IP appelée "uIP". L'ensemble du système d'exploitation est essentiellement conçu autour du réseau et de sa petite sélection de clients et d'outils Internet.
Le COMET 64 est sorti en 2008, en même temps que le lancement du site Web qui l'accompagne, commodoreserver.com. Bien que COMET semble être un modem à port utilisateur avec Ethernet câblé, il est en fait mieux décrit comme un périphérique de stockage et d'échange de données. Tout comme Q-Link, CommodoreServer propose des options de discussion et de jeu en ligne. Lorsqu'un pilote spécial est chargé sur l'ordinateur C64, le modem fournit également un lecteur de disquette Internet sur le périphérique 2, avec tous les fichiers stockés sur le site Web de commodoreserver.com.
Un grand soin a été apporté à l'interface utilisateur de cet appareil, avec une configuration et une utilisation faciles par menus. C'est cet appareil qui a suscité mon intérêt pour les modems Wi-Fi.
L'année suivante, le modem C64Net-WiFi est apparu, suivi peu après par le projet de modem Wi-Fi Strikelink, et plus tard par plusieurs autres périphériques similaires, que l'on peut encore trouver sur eBay pour 25-50 $. Comme le modem de Leif Bloomquist, il s'agit d'appareils à port utilisateur, généralement avec une gestion d'UP9600. Ils ont tous des caractéristiques différentes, mais en commun ils gèrent une variation du jeu de commandes AT de Hayes, ce qui leur donne un niveau de compatibilité avec les programmes de terminal standard du C64/C128.
Plus récemment, le périphérique WiC 64 a également été rendu disponible pour le C64. Il dispose d'une interface utilisateur comme les autres modems Wi-Fi, mais utilise une interface parallèle au lieu d'une interface série. Bien que cela crée encore un autre écosystème logiciel, l'avantage serait l'augmentation de la vitesse par rapport à une interface série.
Le premier de ces appareils à apparaître fut le COMET et le COMET Flyer, les successeurs du modem COMET 64 dont il a été question précédemment. Parallèlement, un autre site Web, commodoreonline.com, a vu le jour, offrant un stockage à distance de disquettes/fichiers similaire à celui de commodoreserver.com.
Le PETDisk Max, de Bitfixer, a été ajouté plus tard au stockage en réseau. Il dispose d'une interface IEEE-488 pour les PET, mais inclut des capacités Wi-Fi pour récupérer des données à partir d'images de disquettes sur le réseau.
Le dernier-né de cette catégorie est le Meatloaf et Fujinet. Bien qu'il ne soit pas encore disponible, le Meatloaf offrirait des caractéristiques similaires à celles du Flyer, à l'exception du fait qu'il utilise des protocoles Web plus standard (WebDAV) pour traiter les images de disquette et les fichiers distants. Il semble qu'il inclura également, en option, un port utilisateur pour la compatibilité avec les modems standard. La relation entre Meatloaf et Fujinet n'est pas claire pour moi, mais il est possible que le Fujinet pour C64 soit basé sur Meatloaf.
La vitesse de l'interface série du port utilisateur du C64 mérite d'être discutée à ce stade. Les Commodore 8 bits les plus populaires, à savoir le VIC-20, le C64 et le C128, ne disposaient pas d'un UART série intégré à l'ordinateur. La communication série était réalisée sur l'interface parallèle 8 bits du "port utilisateur" de l'ordinateur par des routines d'échange de bits intégrées au système d'exploitation, appelé "KERNAL".
Commodore a d'abord annoncé que le port utilisateur du C64 pouvait atteindre une vitesse de 300 bps, mais on a rapidement découvert qu'en contournant un bogue dans la table de synchronisation des bits de KERNAL, la vitesse de 1200 bps pouvaient facilement être gérée. Le C128 pouvait gérer 2400 bps, surtout dans son mode de fonctionnement à 2 MHz. En ignorant le KERNAL et en utilisant des algorithmes de "bit banging" (communication série utilisant un logiciel au lieu d'un matériel) plus étroitement écrits en assembleur (Ilker Ficicilar), des vitesses de 4800 à 7200 bps ont pu être atteintes. En modifiant le matériel, l'UP9600 a permis d'atteindre 9600 bps (Dallmann). Plus récemment, 57 600 bps a été atteint en désactivant la puce vidéo VIC-II et en chronométrant le transfert de bits en comptant les cycles du processeur au lieu d'utiliser les interruptions de temporisation des puces d'entrées/sorties de l'ordinateur (Jorge Castillo).
Le premier objectif était que le micrologiciel apparaisse à l'utilisateur comme un modem de style Hayes/C 1670, et qu'il ait toutes les fonctionnalités attendues d'un tel ensemble de commandes. Le deuxième objectif était que le modem soit un appareil utile pour les ordinateurs qui sont limités à l'exécution de programmes de terminal. Enfin, le modem devait être une plate-forme Internet utile, permettant à l'ordinateur hôte de l'utiliser facilement pour écrire des applications réseau et des jeux personnalisés.
Le jeu de commandes AT comprend toutes les commandes standard et toutes les commandes étendues qui ont un sens pour un modem Wi-Fi, et beaucoup d'autres qui n'en ont pas. Cela inclut des choses comme les codes de réponse, la verbosité, le duplex et le réglage des registres internes pour la réponse automatique et le nombre de sonneries. Ce dernier point n'a peut-être pas beaucoup de sens, mais j'ai essayé de ne pas supposer ce que tous les logiciels de babillard électronique pourraient attendre ou rechercher.
Des commandes ont également été ajoutées pour lister les points d'accès sans fil disponibles et pour se connecter à l'un d'entre eux avec des informations d'identification. Bien que j'aie été l'esclave des bibliothèques d'Espressif pour les types de sécurité sans fil gérés, je n'ai encore rencontré aucun problème dans ce domaine.
ATD, qui est la commande permettant de passer un appel sortant et de se connecter à un numéro de téléphone distant, a été étendu pour autoriser les hôtes Internet et les adresses IP. Lors de la connexion, le modem quitte le mode commande et passe en mode flux, où des octets peuvent être envoyés au système distant et reçus de celui-ci.
La gestion du contrôle de flux matériel et logiciel a également été ajoutée, à l'aide des commandes ATF et ATK.
Par exemple, la commande ATP a été ajoutée pour permettre le décodage de ASCII/ANSI en PETSCII, dont la traduction des couleurs.
L'ATR et l'ATS3 permettent tous deux de modifier le caractère de retour chariot.
La gestion du code "Telnet" a été ajoutée principalement pour satisfaire un serveur Telnet distant en répondant correctement aux requêtes et aux demandes. J'ai rencontré un problème avec les serveurs Telnet distants qui, lorsqu'ils recevaient un code d'échappement Telnet, lisaient immédiatement le caractère suivant. Cependant, lorsqu'il s'agit de paquets réseau, il n'est jamais garanti que tous les octets d'une commande Telnet arrivent dans le même paquet. L'une des nombreuses adaptations que j'ai dû faire au fil des ans a été d'essayer de garantir qu'une commande entière serait toujours contenue dans le même paquet.
Le débit en bauds, ainsi que la possibilité de modifier d'autres paramètres RS232, tels que les bits de données, les bits d'arrêt et les bits de parité, peuvent être modifiés à l'aide de la commande ATB. Bien que la norme 8N1 soit pratiquement universelle, il n'en a pas toujours été ainsi et certains terminaux plus anciens nécessiteront d'autres paramètres.
Cela facilite l'utilisation du serveur de renaissance Q-Link appelé "Q-Link Reloaded". Pour ceux qui l'ignorent, Quantum Link était un service en ligne sur C64, prédécesseur d'AOL.
Le comportement des différentes broches du microcontrôleur peut également être lu ou modifié à l'aide de commandes AT spéciales. Cela s'est avéré important pour les UART qui exigeaient, par exemple, que la broche DCD soit toujours active.
Le micrologiciel gère les mises à jour en direct, de sorte qu'il n'est jamais nécessaire d'utiliser des câbles de programmation ou des logiciels spéciaux pour obtenir la dernière version. Les mises à jour peuvent être vérifiées et téléchargées à la demande à l'aide de la commande ATU. Il est également possible de revenir à des versions spécifiques ou personnalisées en cas de nostalgie. Je l'utilise souvent pour tester des versions avec des fonctionnalités uniques.
Le microcontrôleur fait de son mieux pour maintenir une horloge en temps réel, qui peut être lue à l'aide de la commande ATT. Il initialisera cette horloge via le protocole NTP (Network Time Protocol) au démarrage, et le micrologiciel permettra de régler le fuseau horaire.
Un fichier d'aide pour toutes les commandes AT est accessible à l'aide de la commande ATH, qui conservera le fichier d'aide de la version actuelle après le premier accès pour une consultation hors ligne.
Comme le mode "réponse automatique" des anciens modems, les connexions entrantes peuvent être configurées pour envoyer zéro ou plusieurs messages RING et passer ensuite automatiquement en mode flux. Cela permet aux programmes des babillards électroniques Commodore qui gèrent les modems Hayes ou 1670 de fonctionner dès le départ.
Un "message d'occupation" personnalisé peut également être configuré, de sorte qu'une demande de connexion entrante, lorsqu'une autre connexion utilise déjà le port série, sache qu'elle doit revenir plus tard.
Chaque fois que des données sont reçues de l'une des connexions ouvertes, elles sont présentées sous forme de paquets de données, qui peuvent contenir jusqu'à 255 octets. Ces paquets sont précédés d'un bloc d'en-tête, qui peut contenir des informations telles que l'identifiant de la connexion d'où proviennent les données, la taille du paquet, un CRC de 8 bits du paquet et le numéro de séquence du paquet pour cette connexion. Si le numéro de séquence ou de CRC d'un paquet est incorrect, la commande ATL peut ordonner au modem de retransmettre un paquet précédent.
La commande ATT peut être utilisée pour transmettre un message sous forme de chaîne ou un bloc de données binaires à une connexion ouverte spécifiée. Elle peut également être configurée pour renvoyer le CRC8 du bloc de données qu'elle a reçu par voie sérielle, à des fins de contrôle d'erreur.
Étant donné que les données Internet sont susceptibles d'être reçues beaucoup plus rapidement qu'un ordinateur à 1 MHz ne peut les traiter, il existe plusieurs nouvelles méthodes de contrôle de flux qui peuvent être activées pour gérer les données entrantes. Il s'agit généralement de variantes du contrôle de flux logiciel standard (XON/XOFF) qui opèrent au niveau du paquet et non du caractère. Ces méthodes sont sélectionnées à l'aide de la commande ATF.
Le problème est que le BASIC V2 trouvé dans le VIC-20 et le C64 n'a pas de bonnes fonctions d'analyse de chaînes de caractères, ce qui rend la séparation des données numériques de chaque en-tête de paquet particulièrement pénible. La commande INPUT# en BASIC a également ses propres règles d'analyse plutôt ennuyeuses. Heureusement, à l'époque des babillards électroniques, j'ai appris à créer des chaînes BASIC à partir du langage machine. J'ai donc écrit quelques routines de langage machine pour paquets, que j'appelle "PML", que je peux appeler à partir de BASIC pour analyser rapidement les informations des paquets entrants, en laissant les données dans une variable chaîne BASIC.
Avec cela, j'ai bricolé quelques applications Internet super simples, comme un IRC (Internet Relay Chat) pour la messagerie instantanée, une application FTP (File Transfer Protocol) pour télécharger des fichiers depuis des sites FTP, une application WGet pour télécharger des pages Web ou des fichiers binaires depuis des serveurs Web, et une application d64wget pour télécharger des images de disquettes D64/D71/etc directement depuis un serveur Web sur une disquette vierge. J'ai également écrit un serveur TelnetD qui permet à un utilisateur Internet entrant de "prendre le contrôle" à distance de l'invite C64 BASIC et d'utiliser l'ordinateur comme s'il était assis devant, tant qu'il limite son activité à l'entrée et à la sortie de texte.
J'ai également écrit des programmes de terminal Telnet et PETSCII très simples, à titre d'exemple. Il existe de bien meilleurs programmes de terminal.
Plus que tout, c'est ce que je veux que les gens retiennent et voient dans ce projet. Si un simple jeu BASIC (surtout !) peut être transformé en jeu Internet, alors imaginez ce que quelqu'un qui sait ce qu'il fait peut faire. Pourquoi toutes les applications n'auraient-elles pas une composante réseau, comme c'est le cas pour les logiciels modernes ? Si seulement les applications réseau étaient si faciles à programmer que l'on pouvait le faire en BASIC en envoyant des commandes de chaîne avec PRINT# !
Le modem gère également sans problème le protocole V-1541 et ses services commodoreserver.com, qui existent encore aujourd'hui.
Avec ce nouveau modem, Zimodem a été modifié pour compiler à la fois pour l'ESP-8266 et l'ESP-32, puis d'autres fonctionnalités ont été ajoutées, dont certaines nécessitaient la mémoire supplémentaire ou les fonctionnalités du Gurumodem, tandis que d'autres sont restées dans les deux versions.
C'est à ce moment-là que les objectifs de l'application sont entrés en jeu. Le premier d'entre eux était d'ajouter une commande AT CONFIG qui permettait à de nombreux paramètres de configuration du Wi-Fi et du terminal, y compris le répertoire téléphonique, d'être gérés à partir d'une interface pilotée par menu.
Un client IRC intégré, également piloté par menu, a été ajouté via la commande AT IRC. Cela a été fait principalement sur demande, pour les ordinateurs qui n'ont accès qu'à de simples programmes de terminal.
La gestion SSL/TLS a également été ajoutée, ce qui a permis d'accéder pour la première fois à des sites Web sécurisés. En raison de contraintes, les certificats HTTPS ne sont pas vraiment validés par le client, mais les pages et les données peuvent au moins être lues.
La gestion du client SSH a également été ajoutée, ce qui permet d'établir des connexions de terminal avec des serveurs Linux modernes. Ces connexions peuvent être établies à l'aide d'ATDS, le "S" signifiant "sécurisé". Grâce à cela et à SSL, une grande variété de services et de fonctions sont désormais accessibles par le modem.
Plus tard, mais toujours sur demande, une commande AT PING a été ajoutée.
Comme cela mettrait "l'imprimante" sur un numéro de périphérique non standard, le logiciel Commodore 8 bits n'aura qu'une gestion limitée pour ce système. Le KERNAL, lui, le gère très bien. En ouvrant le périphérique 2 (le modem) et en l'initialisant avec CHR$(8) pour régler 1200 bauds, puis en envoyant la chaîne "AT PRINTP", toutes les données envoyées sur le même canal par la suite seront transmises à l'imprimante configurée. Par exemple, pour imprimer la liste d'un programme BASIC, vous devez entrer :
OPEN4,2,0,CHR$(8):PRINT#4,?at printp?:CMD4:LIST:CLOSE4 |
GEOS, également pour C64 et C128, gère les pilotes d'imprimante appropriés, il était donc relativement simple d'en produire un qui gère les fonctions d'impression réseau du modem. GEOS a un paradigme graphique WYSIWYG pour l'impression ; toutes les impressions sont en fait des images de ce qui était à l'écran. Heureusement, la spécification du protocole IPP prévoit la gestion native d'un format d'image appelé RAS, que CUPS gère également. Le pilote d'imprimante GEOS n'a donc plus qu'à traduire les données de l'image de l'écran en une image au format RAS avant de l'envoyer au modem pour l'impression. Ce projet a été appelé "ras4c64net", et peut être trouvé sur GitHub.
L'Amiga gère également les pilotes d'imprimante, mais la documentation sur la façon de les écrire est beaucoup moins évidente. J'aimerais beaucoup parler à quelqu'un qui en a écrit un, car ce que j'ai trouvé sur Aminet et dans mes livres ne m'a pas plu. Au lieu de cela, je me suis appuyé sur le fait que l'Amiga gère les deux imprimantes sérielles, et que les versions ultérieures d'AmigaOS sont livrées avec un pilote d'imprimante PostScript. J'ai donc ajouté une fonction dans le mode de commande du micrologiciel qui détecterait automatiquement lorsqu'un fichier PostScript est envoyé au modem, et passerait immédiatement en mode d'impression.
L'interpréteur de commandes comprend également un client FTP simple pour récupérer des fichiers sur Internet sur la carte SD formatée.
L'envoi de fichiers de la carte SD vers l'ordinateur hôte se fait par le biais du Shell intégré qui gère le chargement et le téléchargement via le protocole X-Modem, le protocole Z-Modem, ou KERMIT. Ce dernier protocole a été ajouté principalement pour gérer le logiciel de terminal stocké uniquement sur le Commodore 900.
Les commandes de l'interpréteur de commandes peuvent également être saisies directement à partir du mode commande en ajoutant deux points après AT+SHELL suivi de la commande. Par exemple, "AT+SHELL:list" permet de lister le répertoire actuel de la carte SD sur le modem, tout en restant en mode commande.
Le Commodore SuperPET gère nativement un protocole spécial de gestion de fichiers sur le port série appelé "HOSTCM", qui était utilisé pour envoyer des données vers et depuis d'autres ordinateurs centraux. Ce "mode" est activé par la commande AT+HOSTCM.
L'une d'entre elles est la gestion de SLIP/PPoE, qui figure sur la liste des choses à faire depuis le tout début. La possibilité d'exploiter LUNIX et de gérer le navigateur The Wave serait une aubaine extraordinaire. L'intégration avec lwip d'une manière qui ne perturbe pas le fonctionnement normal a été délicate, mais elle est en train d'arriver.
Je suis également impatient d'ajouter la gestion de la numérotation par impulsion au modem, ainsi que l'émulation au niveau des broches du Commodore 1650/1660. Ce serait un ajout extraordinaire à cause de tous les logiciels d'avant 1986 qui deviendraient instantanément compatibles avec lui, dont les programmes de terminal, les logiciels de babillard électronique, et le jeu Modem Wars.
Enfin, un client Gopher intégré a été demandé, pour les utilisateurs de plates-formes extrêmement limitées. Gopher est une idée amusante, car je me souviens avoir pensé à un moment donné qu'il était bien supérieur à HTTP et HTML. Apparemment, il y a encore des gens qui font tourner des serveurs Gopher, donc l'utilité serait immédiate.
Le créateur du WiFi Retromodem sur tempestfpga.com a également créé récemment un modem basé sur l'ESP-32 qui tient dans un vieux boîtier de modem Hayes. Au micrologiciel du Zimodem, il a ajouté la possibilité de jouer les anciens sons du modem à partir d'un haut-parleur, ce qui est absolument délicieux. Peut-être cela sera-t-il bientôt intégré à la branche principale.
Sinon, je suis toujours ouvert aux suggestions et aux rapports de bogues. N'hésitez pas à les publier dans la section "Issues" de mon dépôt Zimodem sur GitHub.
Voilà qui conclut ce très très long retour en arrière sur les solutions Internet pour le Commodore 8 bits, et sur la façon dont mes propres projets se sont insérés dans cette technologie. J'espère que vous avez apprécié la parade et que vous avez peut-être découvert une technologie dont vous n'aviez jamais entendu parler. J'espère aussi sincèrement que vous reconnaîtrez le potentiel des machines 8 bits en tant que clients de réseau, si seulement nous pouvons nous mettre d'accord sur une API.
Voici quelques ressources :
- Page du projet : github.com/bozimmerman/zimodem.
- Page du logiciel du babillard électronique C64/128 : bbs.zimmers.net.
- Le "Zelch BBS" : coffeemud.net:6502
- MMORPG pour vieilles machines : coffeemud.net:23
|
