APPLICATIONSDIVERS ★ LES FICHIERS|CPC REVUE) ★

Les Fichiers|CPC Revue n°28)Les Fichiers|CPC Revue n°29)

GENERALITES FICHIERS OU DOSSIERS ?

Peut-on indifféremment parler de FICHIER ou de DOSSIER ? La question se pose parce que le mot anglais FILE a les deux significations.

Or, un fichier est un ensemble de "fiches" de structure généralement identique.

Exemple : fichier adresse/téléphone.

Toutes les fiches comporteront, par exemple : nom, prénom, adresse, numéro de téléphone.

Un dossier est un rassemblement de fiches de types différents, se rattachant au même objet.

Exemple : dossier de l'ennemi public n° 1 Méfaits commis à Paris, méfaits commis à Marseille, fiche anthropométrique, auditions des témoins, rapport du gendarme Lefutet Adrien, etc.

Le dossier est proche de la notion de base de données. Nous laisserons les dossiers (c'est-à-dire les bases de données) pour l'instant.

TYPES DE FICHIERS

Outre les listes et les arbres qui sont des structures de données "à pointeurs" et les bases de données qui sont des fichiers reliés entre eux (par des pointeurs), on appelle généralement fichiers ou fichiers CLASSIQUES : les fichiers "séquentiels", les fichiers "à accès direct".

Ces appellations sont imprécises et trompeuses.

En effet, un fichier à accès direct (que par souci de concision nous appellerons désormais fichier DIRECT) peut parfaitement être lu de façon séquentielle sur le plan logique (lecture directe mais successive des fiches de 1 à N).

Conservons néanmoins ces appellations, étant entendu que : SEQUENTIEL = lecture de proche en proche à partir de la première fiche.

            = écriture de proche en proche à partir de la première fiche.
DIRECT = lecture OU écriture immédiate de la énième fiche. SUPPORT

Certains supports (on appelle support ce sur quoi l'information est enregistrée) sont inaptes à l'accès direct :

— papier en rouleau
— bande (cassette notamment)

Les supports permettant l'accès DIRECT sont en gros :

— la mémoire centrale
— les disques (auxquels il faut adjoindre un SOFT adéquat que le BASIC des CPC n'a pas).
— on peut également considérer qu'un livre (un dictionnaire, par exemple), permet un certain accès direct puisqu'on peut l'ouvrir à une page quelconque, (voir dessin 1)

LES FICHES

Les fiches sont une suite d'information. En BASIC, chaque information (rubrique) est généralement contenue dans une variable.

Les fiches DIRECTES et donc leurs rubriques ont des longueurs rigidement fixées. C'est le condition nécessaire pour que, connaissant l'adresse du début du fichier, on puisse déterminer la piste et le secteur contenant la fiche n° 347 (347e depuis le début du fichier).

Une zone NOM$ y sera, par exemple, fixée à 30 caractères. De ce fait, MARTIN y sera la chaîne "MARTIN + 24 espaces". Nous en reparlerons.

FICHIERS CLASSIQUES

FICHIERS SEQUENTIELS

En raison des facilités offertes par le traitement DIRECT, les fichiers séquentiels sont souvent, lorsque la mémoire disponible le permet, transférés dans des tables en mémoire centrale.

On effectue alors sur ces tables le traitement adéquat (mise à jour du fichier, par exemple), puis on récrit les tables (lorsqu'elles ont été modifiées) sur un nouveau fichier disque (ou cassette le cas échéant).

Ce processus relève, comme nous venons de le dire, de l'accès DIRECT.

Nous décrirons, le moment venu, les traitements de base des fichiers séquentiels dans le cas où le fichier ne peut tenir entier en mémoire et donc en suivant les contraintes de la logique séquentielle.

CONTENU DES FICHES

En séquentiel, si le nombre et le type des rubriques sont rigidement fixes, la taille de chaque rubrique est fonction :

— de la longueur de l'information (MARTINET est plus long que DUBOIS), et
— de caractères de séparation dépendant du mode d'écriture.

Exemple :
Nom variableContenuNcar.(MEm)Ncar.(Disque/K7)

NOM$
PREN$
TEL$
N.ENF
SALAIRE
ADRESSE$
TAILLE$

MARTIN
jules
67 78 89  34
0
7300
27, RUE VERTE
1,70

6
5
11
2(var.entière)
2(var.entière)
13
5(var. réelle)

> 6
> 5
>11
> 1
> 4
>13
> 4

   

Total: >44

 

Avant de voir le nombre exact de caractères d'une fiche et d'un fichier, notons quelques points importants :

— jules
— 0 enfant (et 7300F)
— 27, RUE VERTE
— Les instructions de lecture et écriture à utiliser.

En ce qui concerne ce dernier point, voir CPC n° 18 "Ecriture et Lecture de fichiers" par Michel Archambault.

A) jules

Dans un fichier, la plupart des zones peuvent servir à une recherche ou être l'objet d'un TRI.

De ce fait, il est conseillé de n'utiliser que les MAJUSCULES. L'usage de UPPER$ est recommandé.

B) 0 enfant

M. MARTIN n'a-t-il pas d'enfants ou le nombre en est-il inconnu ?

Il y a doute si l'information est directement saisie dans une variable numérique, puisqu'ENTER seul donne 0.

C'est une raison de plus pour saisir toutes les zones sous forme de CHAINE (par LINE INPUT).

La question se pose alors de savoir s'il faut enregistrer sur disque ou cassette la donnée sous la forme CHAINE (sous laquelle elle a été saisie et contrôlée) ou la faire passer au préalable dans une variable numérique.

L'une des meilleures solutions est, comme nous le verrons, celle-ci :

a) la donnée est entrée au clavier (LINE INPUT "Nbre d'enfants:";n.enf$):

L'enregistrement est effectué par PRINT #9,n.enf$ (une seule valeur par PRINT # 9)

b) la donnée numérique est calculée par le programme : l'enregistrement est effectué par WRITE#9,n.enf$ (une seule valeur par WRITE#9)

Ici, on doit avoir N.ENF$ et SALAIRES. Les valeurs numériques peuvent, à la relecture, être obtenues de deux façons :

— LINE INPUT$,n.enf$ puis n.enf = VAL(n.enf$), ou
— INPUT#9,n.enf

Un autre problème important est celui de la détermination des zones qui ne doivent, en aucun cas, rester VIDES (zones OBLIGATOIRES) lors de la création de la fiche.

C'est le cas des zones "numériques" puisque VAL ("") donne un ZERO douteux.

La routine du LISTING 1 (voir celle de Michel Archambault dans CPC n° 19) refuse la chaîne dans les cas suivants :

— chaîne vide
— caractère illégal (format exponentiel non admis)
— plus d'un point décimal
— signe en position autre que la 1ers
— nombre de chiffres nul ou > ne (ne étant un paramètre pouvant être compris entre 1 et 9).
— espaces au début ou en fin
— valeurs en "OVERFLOW" si la variable réceptrice est entière.

Remarques

— Le contrôle de la donnée après saisie complète de la zone (et non par rejet immédiat du caractère erroné lors de la frappe) est tout à fait admissible sur CPC, la touche COPY permettant de recomposer la donnée correcte très rapidement. Généralement, les erreurs sautent aux yeux, sauf les espaces en fin de chaîne, d'où le doublement du CHR$(7).
— Les espaces de début et de fin sont habituellement à éviter. Il est inutile de gaspiller une place disque mesurée. Mais voici le cas d'un fichier CADRE d'écran où ils seraient nécessaires :

LIGNE1 $:.....................ETAT des STOCKS
LIGNE2$:.....................---------------------

etc.

Les points figurent les blancs à gauche.

— Il faudrait penser à bien d'autres choses. Par exemple, certaines zones "chaîne" composées uniquement de chiffres doivent être cadrées de zéros à gauche pour qu'un tri éventuel ait un sens ("21 " est plus grand que "127" mais "00127" est plus grand que "00021".

c) 27, RUE VERTE Le problème n'est pas la couleur de la rue, c'est la virgule. Lorsque celle-ci existe, le problème dépend du couple d'instructions écriture/lecture utilisé.

Ecriture : PRINT #9
Lecture : INPUT #9
Problème VIRGULE : OUI (la valeur de adresse$ sera “21", celle de tai!le.$ sera "RUE VERTE" etc...)

PRINT #9        LINE INPUT #9     NON
------------------
WRITE #9        LINE INPUT #9     NON
  "  "                INPUT # 9             NON

LONGUEUR DES FICHES ET DES FICHIERS

1ere solution :

Si l'on a écrit : PRINT# 9, adresse$ (UNE SEULE valeur avec PRINT# 9 s.v.p), la rubrique sur K7 ou disque fera 13 + 2=15 caractères (les deux caractères de fin sont en Hexa OD et OA (carriage return et line feed)

Chaque rubrique devra être relue par LINE INPUT # 9, sauf si la saisie des données a rejeté les virgules (ce qui, à notre avis, est souvent une saine mesure).

A ce propos, recevez-vous beaucoup de courrier publicitaire où une virgule figure dans votre adresse ?

Dans ce dernier cas, on peut remplacer la série de LINE INPUT#9 par :

INPUT#9, nom$, pren$, tels$, n.enf$, salaire$, adresse$, taille$

ou par

INPUT#9, nom$, pren$, tel$, n,enf, salaire, adresse$, taille!

La longueur de la fiche est obtenue en ajoutant 2 à la longueur de chaque rubrique (présente ou absente, une rubrique vide faisant 0 + 2 = 2 caractères): soit 44 + 14 = 58 caractères.

Le nombre de caractères "utilitaires" du fichier est : (N.rubr * 2) * N.fiches + 1 (caractère 1A dit Ctrl-Z de fin de fichier).

Soit 20 001 caractères pour 1000 fiches ayant chacune 10 rubriques.

La 2e solution, que nous allons voir, est bien pire.

Nota : on pourrait être tenté d'économiser quelques caractères en enregistrant de la façon suivante :

PRINT#9, nom$: PRINT#9, pren$: PRINT#9, tel$
WRITE #9, n.enf, salaire PRINT# 9, adresse$
WRITE #9, taille!

Le gain serait très exactement d' 1 caractère par fiche, les deux caractères de séparation entre n.enf et salaire (&0D et &0A) étant remplacés par une virgule.

Mais cette virgule interdira de se servir de LINE INPUT #9 à la relecture.

D'où la suggestion de ne mettre qu'une seule valeur numérique calculée par WRITE #9. Nous pensons d'ailleurs être ainsi fidèles à la pensée du professeur Archambault.

2e solution :

Si l'on a écrit :

WRITE#9, nom$, pren$, tel$, n.enf$, salaire$, adresse$, taille$ la longueur de la fiche est obtenue en ajoutant à la longueur de chaque rubrique :

2 caractères < " > soit pour 7 rubriques = 14 caractères 1 caractère < , > après 6 rubriques = 6 caractères
Le 0D et le OA de fin de fiche = 2 caractères soit en tout 40 + 22 = 62 caractères.

Le fichier sera lu par :

INPUT#9, n$, p$, t$, etc.

Le nombre de caractères "utilitaires" du fichier est : (N.rubr* 3 + 1) *N. fiches + 1

Soit 31 001 caractères pour 1000 fiches ayant 10 rubriques. Cette solution est à écarter.

3e solution :

Elle est la plus économe en place disque; le nombre de caractères utilitaires étant :

(N.rubr + 2) *N. fiches + 1

soit 12 001 caractères pour 1000 fiches ayant 10 rubriques. Le procédé consiste à concaténer en une seule chaîne les différentes rubriques. La longueur maxi de la fiche est de 255 caractères.

Pour pouvoir distinguer les rubriques entre elles, celles-ci sont précédées, si on se limite à 54 rubriques (ce qui semble confortable), par le caractère :

CHR$(200 + Nr.Rubr.)

Dans notre exemple, la chaîne commencerait par : ~ 201 ~ MARTIN ~ 202 ~ JULES......ou ~ 201 ~ représente CHR$(201 )

Le nombre maxi de caractères utiles pour une fiche est donc : 255 - Nbre de rubriques.

Il est donc de 254 pour une seule rubrique et de 201 pour 54 rubriques.

Ces restrictions n'empêchent pas cette formule d'être intéressante lorsqu'on manque de place. La programmation de cette solution sera donnée par la suite.

PERFORMANCES

Nous avons enregistré 999 fois la même fiche (MARTIN JULES etc.) faisant 43 octets utiles (la virgule de l'adresse étant supprimée) et pour la 1000® fiche, JULES a été remplacé par JULOT.

Chaque programme de lecture devait rechercher cette fiche particulière.

On obtient :

SOLUTION 1 - Ecr. 56 s. - Lect. 62 s - Taille 56K - Mode Ecr/Lect PRINT#9/LINE INPUT #9
SOLUTION 2 - Ecr. 57 s. - Lect. 66 s. - Taille 64K - Mode Ecr/Lect WRITE # 9/INPUT # 9
SOLUTION 3 - Ecr. 44 s - Lect. 51 s. - Taille 51K - Mode Ecr/Lect rubriques concaténées (PRINT #9/LINE INPUT #9)

Notas :

A) Taille

Les calculs auraient donné :

Solution 1 -43000 + 14001 = 57001 car./1024 = 55.7 K
Solution 2 - 43000 + 22001 = 65001 car./1024 = 63,5 K
Solution 3 - 43000 + 9001 = 52001 car./1024 = 50.8 K

B) Vitesse

Les solutions classiques 1 et 2 mettent à chaque lecture les valeurs à la disposition du programmeur dans les variables. Pour réaliser la même chose avec la solution 3, il faudrait, après chaque lecture par LINE INPUT#9, procéder au "dégroupage" des rubriques.

Voir le listing 2.

Ce dégroupage prend du temps, mais il n'est nécessaire pour chaque fiche que lorsqu'on traite l'ensemble du fichier (fichier Personnel lors de la paye par exemple). Si l'on fait une simple recherche, seul le dégroupage de la fiche intéressante sera nécessaire.


En fait, une recherche séquentielle d'une seule fiche étant toujours longue, ce procédé a, dans ce cas, l'avantage d'une moindre lenteur. Si T est le temps total (lorsque la fiche recherchée est la dernière, la durée moyenne d'une recherche est de T/2).

RECHERCHE

SUR CASSETTE OU SUR DISQUE

Il résulte des considérations précédentes que la longueur d'une fiche est fonction du nombre de caractères de chaque rubrique et aussi du mode d'enregistrement.

Dans ces conditions, il est impossible de connaître, même sur disque, l'adresse d'une fiche à part celle de la première qui correspond à l'adresse de début de fichier.

Cette adresse de début est conservée dans le répertoire (DIRectory ou CATalogue).

On ne peut donc trouver une fiche qu'en lisant les fiches les unes après les autres et en regardant si la fiche lue contient une valeur repère appelée (de façon détestable) CLE.

Par ailleurs, tout fichier se termine par le caractère &1 A (ctrl Z) qui est écrit par CLOSEOUT. Ce caractère &1 A est détecté, à la lecture, par la fonction EOF (End Of File = fin du fichier). La fonction EOF a alors la valeur - 1 (valeur 0 avant la fin de fichier).

Nous pouvons représenter la recherche d'une fiche par :

a) L'algorithme verbal :

1 - Ouvrir "TOTO" en lecture
2 - Critère (CLE)?
3 - Si fin du fichier (EOF, voir manuel) aller à l'étape 9 sinon lire une "fiche" (c.a.d la 1ere ou la suivante)
5 - Si la ZONE choisie contient CRITERE aller à l'étape 7
6 - Sinon retourner à 3
7 - Afficher Fiche
8 - Si "on recherche les autres" retourner à 3, sinon aller en 9
9 - Fermer "TOTO": FIN.
ou par un ordinogramme (ou organigramme): voir l'organigramme A.

Il existe au moins 2 autres façons d'exprimer les algorithmes :

— par du simili-BASIC
— par du PASCAL

Cette dernière méthode ne sera pas utilisée, la connaissance de ce langage n'étant pas encore assez répandue. On peut d'ailleurs penser qu'un BASIC structuré comme TURBO BASIC sera, dans le futur, un excellent moyen de représentation des algorithmes.

Le simili-BASIC pourrait donner :

WHILE NOT EOF OR zone$<>Cle$
lire 1ere fiche ou la suivante WEND
IF EOF THEN RATAGE ELSE BRAVO
BRAVO:
PRINT nom$
PRINT pren$
etc
GOTO SUITE
RATAGE:
PRINT "pas Trouve"

SUITE. '...suite...

RECHERCHE EN MEMOIRE CENTRALE

Nous vous proposons de chercher une "CLE" de valeur 4567 dans une table de valeurs numériques définie par :

DIM nr (2000)
L'indice ZERO est négligé.
A - Solution standard
Elle prévoit ô chaque itération :
La comparaison de l'élément nr (k) et de la CLE.
La comparaison de l'indice K et de l'indice maximum 2000
Ce dernier test est destiné à éviter l'erreur "Subscript out of range"
B - Méthode de la SENTINELLE
On peut supprimer cette deuxième comparaison en plaçant en bout de table une SENTINELLE.
On écrit : DIM nr (2001)' 1 élément supplémentaire (la guérite) nr (2001) = cle
L'organigramme B se passe de commentaire.

Cette méthode très intéressante avec les langages compilés ou en assembleur, ne l'est pas en BASIC interprété où la boucle FOR..NEXT reste la façon la plus rapide de parcourir une table (ceci pour des raisons de programmation de l'interpréteur).

FUSION

GENERALITES

La fusion (MERGE) à distinguer de APPEND (mettre bout à bout), c'est entremêler de façon harmonieuse deux ou plusieurs fichiers ou tables préalablement triés de la même façon. La fusion est souvent utilisée dans le cas suivant :

— on se propose de trier en mémoire un fichier enregistré sur disque.
— le fichier est trop gros, on ne peut charger qu'un peu plus du tiers des fiches.
— en conséquence, on appelle en mémoire et l'on trie ces trois parties appelées A, B et C qu'on écrit successivement sur disque.
— on fusionne alors A et B, ce qui donne D.
— enfin, on fusionne D et C pour avoir E. C'est le fichier complet sous sa forme triée.

Lorsqu'on ne peut ouvrir qu'un seul fichier en entrée (OPE-NIN unique), on peut procéder comme suit :

— ayant un morceau, par exemple A, trié en mémoire
— on fait OPENIN"B" et l'on crée ce dernier
— on appelle C en mémoire et de la même façon on le fusionne avec D pour avoir E.

FUSION DE 2 TABLES OU FICHIERS

Point important : nous supposons qu'il y existe des arguments de tri homonymes. Par exemple, plusieurs "MARTIN", si l'on trie sur le nom.

Les organigrammes C1 et C2 donnent une solution convenable du problème.

Il faut noter :

— la nécessité de relire immédiatement le fichier dont on vient d'écrire la fiche sur le fichier en sortie.
— la façon de traiter les fins de fichiers en mettant à la valeur maximum la zone du fichier en EOF.

Bien que la fusion de 2 fichiers puisse, de proche en proche, venir à bout de toutes les situations, il peut être intéressant de se poser le problème suivant :

Fusion en une SEULE passe de N (par exemple 5) fichiers en un seul.

A la place de "fichiers" il y a lieu, éventuellement, de comprendre "tables". La solution sera proposée ultérieurement.

MISE A JOUR

Il s'agit là de l'opération fondamentale de ce que l'on appelle la Gestion de Fichiers.

Les trois opérations de base de la mise à jour sont les suivantes :

— ADDition d'une fiche --> ADD
— Suppression d'une fiche --> SUP
— MODification d'une fiche --> MOD

NECESSITE DU TRI

Un fichier séquentiel doit toujours être trié sur un (ou plusieurs) critères de recherche pour en permettre l'exploitation.

Ainsi dans l'annuaire des abonnés au téléphone, le classement est fait sur :

— Localité
— Nom
— Prénom
— nom de la voie

Ceci ne serait pas nécessaire sur ordinateur si, d'une part, on ne cherchait qu'une seule fiche à la fois et si d'autre part il n'y avait qu'une seule fiche correspondant à la clé de recherche.

En effet, fichier trié ou pas, le temps de recherche est EN MOYENNE celui qu'il faut pour lire la moitié de ce dernier. Si le fichier est trié, le premier avantage sera d'avoir les 34 MARTIN qui y figurent, groupés. Le deuxième est que lorsqu'on aura trouvé le MARTIN ROBERT qui nous intéressait et qu'il s'agira alors de trouver le nommé VISTAMBOIR

JULES, il suffira de continuer la lecture sans être obligé de la recommencer au tout début.

UN PROGRAMME DE MISE A JOUR

Remarques préalables :

Avant de décrire le fonctionnement du programme, précisons les points suivants :

Généralité du programme

Un programme de mise à jour doit être valable pour le plus grand nombre possible de fichiers différents.

Le premier enregistrement (fiche) du fichier décrit le fichier lui-même (voir les DATA à la fin du programme). En le lisant, le programme MAJSEQ1 sera informé sur la structure des fiches suivantes.

Ce premier enregistrement a donc un format différent de celui des autres fiches.

Notons qu'ici le fichier n'est pas complètement décrit. On pourrait ainsi ajouter des DATA pour les informations suivantes :

— rubrique Obligatoire, Facultative (chaîne vide autorisée).
Par exemple :

DATA 0, F, 0 (on ne peut pas taper le prénom (cf. programme)).

— rubrique numérique avec ZEROS A GAUCHE.

Noms des fichiers

Le nom du fichier ENTREE est, bien sûr, fixé par l'opérateur. Par exemple, "FICH.CLI".

Celui du fichier SORTIE en sera déduit en ajoutant au nom principal le suffixe "OLD".

Ainsi, on aura OPENIN "FICH.CLI" et OPENOUT "FICH.OLD". La mise à jour achevée, le programme permutera ces deux noms. Le nom du fichier en entrée sera donc toujours le même ainsi que celui de la version précédente (.OLD).

Pourquoi ne pas utiliser le suffixe ".BAK" au lieu de ".OLD" ? Parce que les nettoyages du style IERA,*.BAK, si pratiques, supprimeraient la version précédente, version qui permet de reconstituer le fichier en cas d'incident.

Il faut noter que lorsqu'on fait OPENOUT "FICH.OLD", le système renomme ce fichier qui devient "FICH.BAK".

On aurait donc, en fin de Mise A Jour, après échange des noms :

— édition n FICH.CLI (écrit sous le nom FICH.OLD)
— édition n-1 FICH.OLD (lu sous le nom FICH.CLI)
— édition n-2 FICH.BAK (sauvegarde de l'ancien .OLD) Outre que les fichiers .BAK sont, nous l'avons vu, promis à une mort subite, le surcroît de sécurité donné par la possession de 2 générations antérieures ne compense pas le surcroît d'encombrement disque ainsi créé. En conséquence, le fichier OLD sera tué avant l'OPENOUT ".OLD" pour éviter sa sauvegarde ".BAK".

On pourra, de la sorte, avoir des fichiers d'environ 80 K avec une disquette et de 160 K avec deux.

Le programme MAJSEQ1 est prévu pour un lecteur (d'où le 1 ). On trouvera en tête de programme ce qu'il faut faire pour travailler avec 2 lecteurs.

Dans ce dernier cas, la disquette qui était en 1 sera mise dans le lecteur B à la mise à jour suivante et vice versa. Lorsqu'on a deux lecteurs, travailler ainsi est beaucoup plus sûr que de laisser les deux générations sur la même disquette.

CPC

★ EDITEUR: CPC Revue
★ ANNÉE: 1987
★ CONFIG: 64K + AMSDOS
★ LANGAGE:
★ LICENCE: LISTING
★ AUTEUR: Bernard BESSE

 

★ AMSTRAD CPC ★ DOWNLOAD ★

Type-in/Listings:
» Les  Fichiers    (CPC  Revue)    (Organigrammes)    FRENCHDATE: 2019-12-19
DL: 3 fois
TYPE: PDF
SIZE: 1515Ko
NOTE: Uploaded by hERMOL ; 1 page/PDFlib v1.6

» Les  Fichiers    (CPC  Revue)    FRENCHDATE: 2019-12-19
DL: 4 fois
TYPE: ZIP
SIZE: 9Ko
NOTE: 40 Cyls
.HFE: NON

Je participe au site:
» Newfile(s) upload/Envoye de fichier(s)
★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):

QUE DIT LA LOI FRANÇAISE:

L'alinéa 8 de l'article L122-5 du Code de la propriété intellectuelle explique que « Lorsque l'œuvre a été divulguée, l'auteur ne peut interdire la reproduction d'une œuvre et sa représentation effectuées à des fins de conservation ou destinées à préserver les conditions de sa consultation à des fins de recherche ou détudes privées par des particuliers, dans les locaux de l'établissement et sur des terminaux dédiés par des bibliothèques accessibles au public, par des musées ou par des services d'archives, sous réserve que ceux-ci ne recherchent aucun avantage économique ou commercial ». Pas de problème donc pour nous!

CPCrulez[Content Management System] v8.7-desktop/cache
Page créée en 143 millisecondes et consultée 79 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.