1. Le MCDV vu du PC
2. Le MCDV vu du DAI
   1. Version avec module résidant en RAM
   2. Version avec module résidant en ROM
   3. But :
3. Développement du projet
   1. Les choix
   2. Modules en cours de développement
      1. PC-RS232-CLIENT

Pour prendre connaissance des motivations ayant donné lieu à ce nouveau projet : suivre ce lien.

S'il voit le jour, alors il permettra à l'utilisateur de lire ou d'écrire des programmes DAI à partir d'un PC local ou d'un PC situé n'importe où sur l'Internet.

Il s'agit donc de construire un programme exécutable qui une fois lancé offrira à l'utilisateur, une interface permettant de choisir :

1. La localisation de la base de données (en local ou sur un site distant)
2. Si le MCDV doit être utilisé avec un DAI réel disposant du module "DAI-MCDV-RAM" en RAM (CF explications plus loin).
3. Si le MCDV doit être utilisé avec un DAI réel disposant du module "DAI-MCDV-ROM" en ROM (CF explications plus loin).
4. Si le MCDV doit être utilisé avec un émulateur de DAI style MESS.
5. Si le MCDV doit être utilisé avec un autre MCDV situé sur un PC distant quelque part dans le monde. Dans ce cas, le MCDV fait fonction de serveur distant pour un DAI situé quelque part...

Le MCDV vu du PC

Vu du PC, les choses sont assez complexes. Il s'agit de découper le travail en modules et pour cela, commençons par un petit schéma. Les commentaires suivent le schéma.

Le schéma : tout d'abord il convient de préciser que ce qui existe déjà par l'intermédiaire du prototype correspond à la zone sur fond bleu clair.

En bas du schéma on distingue 3 parties.

1. A gauche on reconnaît le DAI. Un pavé XOR indique qu'il se trouvera dans l'une ou l'autre des configurations "DAI-MCDV-RAM" ou "DAI-MCDV-ROM". Ce que cela signifie, vous le saurez en lisant plus bas, le chapitre "2) Le MCDV vu du DAI" En résumé il s'agit soit d'une configuration "facile" dans la laquelle vous n'aurez aucun matériel à installer côté DAI, soit d'une configuration plus musclée mais qui nécessitera de remplacer le module MEMOCOM (si vous en avez déjà un) ou de le créer si vous n'en disposez pas. Je vous rassure, nous n'en sommes pas encore là !
2. Au mileu on devine un émulateur de DAI (MESS par exemple). Ceci signifie que j'ai prévu de faire des efforts pour pouvoir offrir à l'émulateur une prise permettant d'utiliser le MCDV.
3. A droite, on voit un module "Interface Fichiers distants" qui est censé se trouver quelque part sur la planète.

Dans le bas de la partie principale, on voit :

1. un module "PC-RS232-CLIENT" qui permet de charger le programme "DAI-MCDV-ROM" automatiquement dans la mémoire du DAI si l'on n'a pas décidé de construire la version ROM. Dans le cas contraire, le module "PC-RS232-CLIENT" ne sera d'aucune utilité.
2. Un module "PC-RS232-SERVEUR" qui permet au DAI a) de charger des fichiers (commandes LOAD, LOAD ou R) - ce qui correspond aux flèches bleues - b) de sauvegarder des fichiers (commandes SAVE, SAVEA, W) - ce qui correspond aux flèches rouges.
3. Un module "PC-MESS-SERVEUR" qui permet à un émulateur MESS de charger des fichiers (commandes LOAD, LOAD ou R) - ce qui correspond aux flèches bleues - b) de sauvegarder des fichiers (commandes SAVE, SAVEA, W) - ce qui correspond aux flèches rouges.
4. Un module "PC-TCP_IP-SERVEUR" qui permet à un MCDV situé sur Internet de charger des fichiers ce qui correspond aux flèches bleues - b) de sauvegarder des fichiers - ce qui correspond aux flèches rouges. Ceci permet donc à un DAI ou un MESS de se servir d'un MCDV situé à un endroit quelconque.

En  remontant dans la partie centrale, on distingue des bôites "XOR" rouges et bleues. Ceci indique que pour une instance de MCDV chargée dans la mémoire d'u PC, l'un seulement des 3 derniers modules présentés sera actif. Mais rien n'empêchera de lancer une autre instance ce qui ouvre d'autres possibilités que je vous laisse imaginer.

En remontant encore, on constate qu'une des fonctions de l'interface utilisateur est d'activer les modules, ce qui est symbolisé par les pavés mauves et ce qui complète l'explication précédente. Ainsi, le premier des pavés mauves à partir du bas permet d'activer le module "PC-RS232-CLIENT" et éventuellement le chargeur ou d'activer le module "PC-MESS-SERVEUR"  ou d'activer le module "PC-TCP_IP-SERVEUR". Enfin, le pavé mauve mauve du haute permet d'activer le module "Interface fichiers locaux" ou le module "Interface fichiers distants".

Une fois ces activations faites, le module "dispatcher" (aiguilleur) sait vers quelle interface il faut envoyer les requêtes venant des modules du bas. Il les route donc soit vers l'interface fichiers locaux soit vers l'interface fichiers distants.

Dans la partie haute du schéma, on voit :

1. Le module "Interface fichiers locaux" dont le but est de lire ou d'écrire des programmes DAI sur PC. Il s'agit en fait d'un système de fichiers déposés dans un répertoire.
2. Le module "Interface fichiers distants" dont le but est de lire ou d'écrire des programmes DAI sur un PC distant.

Le MCDV vu du DAI

Vu du DAI, les commandes suivantes devront être possibles :

LOAD ["NomProgramme"] pour charger un programme (BASIC)

LOADA var ["NomFichier"]pour charger un tableau (en BASIC)

SAVE ["NomProgramme"] pour sauvegarder un programme (BASIC)

SAVEA var ["NomFichier"] pour sauvegarder le contenu d'un tableau (BASIC)

R [NomFichier] pour lire un fichier binaire (mode moniteur)

Wadr1 adr2 [NomFichier] pour écrire un fichier binaire (mode moniteur)

Ces commandes devront donc lire et écrire des données sur le magnétophone virtuel (MCDV) présent sur un PC.

Les module DAI permettant de réaliser le dialogue avec le MCDV peuvent être réalisés de deux façons différentes, soit par un un programme résidant en mémoire RAM, soit par un programme résidant en ROM à la manière de ce qui se fait pour le MEMOCOM.

Ce projet commencera par implémenter la solution mémoire RAM pour que le plus grand nombre d'utilisateurs puissent en profiter. Toutefois, cette solution comporte des désavantages que nous évoquerons bientôt.

Lorsque le projet sera suffisamment complet avec la solution RAM, nous nous pencherons sur un nouveau module résidant en ROM.

Version avec module résidant en RAM

Nom du module à développer : DAI-MCDV-RAM

But :

disposer en mémoire RAM, d'un programme (aussi compact que possible) permettant d'implémenter les fonctions LOAD, LOADA, SAVE, SAVEA, R et W de manière à ce que les demandes d'entrée/sortie ne se fassent plus ni sur l'interface cassette ni sur l'interface MEMOCOM mais sur l'interface RS232.

Ce module devra dialoguer avec un autre module fonctionnant sur un PC et ce, via l'interface série RS232 présente sur le DAI.

Avantage :

cette solution ne nécessite pas de modifier le matériel DAI. Il nécessite tout au plus de réaliser un câble de liaison.

Inconvénients :

1. Ce module devant résider en RAM, il occupe de la place en mémoire (le pauvre DAI ne contient que 48 KiO de mémoire...).
2. Il faut trouver un moyen de charger automatiquement ce programme en mémoire. Ceci sera pris en compte par un chargeur sous le contrôle du PC. C'est donc le PC qui aura la responsabilité de charger ce module dans la mémoire du DAI.
3. Quelle que soit la plage mémoire qu'on va assigner à ce module, il est susceptible d'être écrasé par le chargement d'un programme. Ceci pose un grave problème qui complexifie le développement de ce module et du chargeur associé. Pour résoudre ce problème, il faut au choix :

1. disposer d'un disposer d'un module intelligent qui se déplace tout seul en mémoire dès qu'il se rend compte qu'il est en train de se recouvrir par une opération de chargement de programme.
2. disposer de plusieurs versions compilées de ce module aptes chacune à fonctionner dans une zone précise de la mémoire. Auquel cas, il faut que l'utilisateur connaisse par avance la zone mémoire du programme qu'il compte charger et que de surcroît il ait une action manuelle (au niveau du PC) pour charger le bon module. Ceci était la solution choisie pour le prototype. Vous pouvez voir dans le menu du prototype les options a b et B correspondant à 3 versions de ce module tournant respectivement dans les plages d'adresse démarrant respectivement en A000, 2EC et 2000.

Quelle que soit la solution "RAM" choisie, elle ne répondre à tous les cas, par exemple nous pouvons parfaitement vouloir sauvegarder et restaurer toute la mémoire du DAI allant de 2EC à BFFF par exemple et dès lors, où caser le module ? Il sera forcément écrasé. Heureusement, la plupart des programmes se contentent d'une partie de la mémoire, ce qui rend la solution décrite faisable. Je dois d'ailleurs dire que je n'ai pas rencontré de programme sauvegardant toute la mémoire.

Choix de réalisation :la rapidité et la simplicité de développement y gagneront ce que la commodité y perdra, mais nous prendrons d'abord la décision d'implémenter une solution basée sur 2 versions de ce module, l'une en mémoire basse et l'autre en mémoire haute. Lors du chargement de ce module, si l'utilisateur n'indique pas de préférence c'est la mémoire haute qui sera privilégiée.

Version avec module résidant en ROM

Nom du module à développer : DAI-MCDV-ROM

But :

Disposer en ROM, en lieu et place du module MEMOCOM, d'un programme permettant d'implémenter les fonctions LOAD, LOADA, SAVE, SAVEA, R et W ainsi que toutes les commandes du MEMOCOM (SKIP, REW etc).

Avantage :

1. Aucun programme en cours de chargement ne pourra effacer ce module, ce qui rend la solution parfaitement fiable et parfaitement apte à remplacer le MEMOCOM.
2. Cela simplifie la partie PC puisque la partie chargeur n'a alors plus lieu d'être.

Inconvénients :

Il faudra programmer une EPROM.

Développement du projet

Les choix

Nom de l'exécutable à produire : MCDV.EXE

Système d'exploitation : Windows 32.

Environnement de développement : DEV-C++

Langage : C

Modules en cours de développement

PC-RS232-CLIENT