Un article qui va révolutionner l'univers impitoyable de la saisie de datas ! Est proposée en effet une méthode (avec les programmes) d'écriture de datas économique pour tous ceux qui diffusent par voie de presse leurs programmes en langage machine. En plus sont inclus une somme de contrôle et une vérification des interversions. LE PROBLEME Un programme en langage machine ne peut être diffusé par vole de presse sous forme de code alors que pour un programme en BASIC, il suffit d'Imprimer le listing. Publier uniquement le source obligerait d'abord le lecteur à disposer de l'assembleur nécessaire à sa traduction et surtout serait Inintéressant pour 90% du lectorat, sans compter le grand nombre de pages que cela nécessiterait. Aussi le code est-Il traduit en lignes de DATAs. Il peut alors y en avoir beaucoup; peut-être certains ont-ils gardé le souvenir de MEGA SOUND ou de AXYS.
Le code est une suite d'octets. Chaque octet prend une valeur entre 0 et 255 décimal ou 00 et FF hexadécimal. La méthode ultraclassique de conversion en DATAs est de prendre la valeur hexadécimale. Cela donne des lignes de ce genre: 220 DATA 01 ,C4,7F,ED,49,21 ,00,C0,11, 00,40, D5,C1 ,ED,B0,C7Il est clair que la traduction d'un octet nécessite 3 signes (sauf en bout de ligne): 2 pour la valeur hexadécimale et un pour le séparateur (la virgule Ici). Or chaque signe en ligne DATA occupe 1 octet. Donc la transcription en DATAS de code par ce système occupe 3 fols plus de place que le code même. Supprimer les virgules ramènerait le rapport de 3 à 2 mais la lecture d'une suite de signes est d'autant moins aisée que la ligne est longue et que le nombre de signes différents est réduit. Les 16 chiffres de l'hexadécimal sont Justement trop peu nombreux.
Ayant Intensément réfléchi à la question, j'ai imaginé un autre système de traduction de code en DATAs, plus économique que l'habituel (même sans les virgules!) et pas plus fatigant à lire (à mon avis). Je propose ma solution; le peuple, pardon, le lectorat, disposera. 
LA SOLUTION L'Idéal serait évidemment de traduire 1 octet par 1 signe en ligne DATA. Comme il y a 256 valeurs d'octet. Il faudrait 256 signes différents. D'une part l'imprimante aurait du mal à produire autant de signes sans une lourde programmation en temps réel, Or on doit pouvoir se contenter d'une simple Impression de programme BASIC. D'autre part, il faudrait recourir à une bonne gymnastique sur le clavier avec SHIFT et CONTROL pour taper autant de signes; et encore cela requérerait-il avant des redéfinitions de touches. Or de même qu'on doit pouvoir se contenter d'une simple Impression (LIST #8) pour obtenir le listing, de même on doit se contenter du clavier standard pour taper le programme. Ces 2 faits ont constitué mon fil directeur pour ma recherche. Partant des (utopiques) 256 signes, J'ai envisagé la moitié, 128, mais c'était encore trop. Divisant encore par 2 J'ai abouti à 64 (sl^ll). Voilà une valeur sympathique, et pour plusieurs raisons ! - Il est aisé de produire 64 signes avec le clavier: l'alphabet comporte 26 lettres; avec les majuscules et les minuscules, cela fait 52 signes. Ajoutons-y les chiffres, sauf le 1, qui se confond aisément avec le L mimuscule "l". Cela fait 52+9, soit 61 (et sans calculatrice!). Ne manquent à l'appel que 3 signes. Constatant qu'il y a dans le monde du CPC des claviers QWERTY et des AZERTY, J'ai choisi 3 signes facilement accessibles sur les 2 types, à savoir le trait d'union *-"« la barre de division */" et le point virgule ";",
- tous les signes choisis sont Imprimables directement (c'est presque une Lapalissade, mais il fallait le dire).
- la dernière raison est mathématique: avec 64 signes, on ne peut traduire que 64 valeurs différentes à raison de 1 signe pour 1 valeur. Or un octet peut prendre 256 valeurs différentes. Un octet est codé sur 8 bits (8 signes binaires): 256 = 2 A 8. Quant à un nombre entre 0 et 63 (64 signes), il tient sur 6 bits: 64 = 2 A 6. Donc pour coder 1 octet, on va devoir lui enlever 2 bits, bits que l'on va stocker ailleurs. Pour 3 octets on va obtenir un reliquat de 6 bits, qui est justement la taille du codage d'un signe. Ainsi on va traduire 3 octets consécutifs par 4 signes. Fabuleux rapport de 4/31
Un dessin valant parfois mieux qu'un long discours, voici une représentation schématique du système: soit 3 octets consécutifs: X, Y et Z
— hexa: XHXL ; YHYL ; ZHZL
— binaire: X1X2X3X4X5X6X7X8 Y1Y2Y3Y4Y5Y6Y7Y8 Z1Z2Z3Z4Z5Z6Z78
;(8 BITS)
Pour chacun on ne garde que les 6 derniers bits, 3 à 8.
On obtient: X' ; Y' ; Z'
; X3X4X5X6X7X8 ; Y3Y4Y5Y6Y7Y8 Z3Z4Z5Z6Z7Z8
; (6 BITS)
On réunit les 3 paires de bits supérieurs (1 et 2)
en 1 bloc de 6 bits: ZYX'
;Z1Z2Y1Y2X1X2
;(6 BITS)
On obtient un bloc de 4 signes pour traduire 3 octets:
X' ; Y' ; Z' ; ZYX'
X3X4X5X6X7X8 Y3Y4Y5Y6Y7Y8 Z3Z4Z5Z6Z7Z8 Z1Z2Y1Y2X1X2Il s'agit donc d'une distribution des bits de 3 signes de 8 bits sur 4 de 6 bits. 3 * 8 = 4 * 6: Il n'y a pas de place gaspillée. La seule contrainte par rapport au système classique est qu'on travaille Ici avec des triplets d'octets: la longueur du code doit pouvoir être un multiple de 3. Au pire il n'y a jamais que 2 octets de traduits en trop! Pour rester fidèle à un nombre classique, et pour comparer, j'ai choisi de traduire 16 octets en une ligne DATA. Or je viens d'expliquer que le système fonctionnait avec des triplets d'octets. En y ajoutant 2 octets pour la somme de contrôle, cela fait 18 (6*3). Le rapport de conversion étant de 4/3, on obtient donc 24 signes. C'est pratiquement 2 fois moins que les 47 (15*3+2) nécessaires pour traduire ces mêmes 16 octets selon la méthode classique.
Il peut arriver qu'il y ait dans du code des suites d'octets identiques. Cela peut se traduire par des suites de signe en rapport de 4/3 en longueur, mais pas toujours; cela dépend de l'écriture binaire de l'octet: - considérons l'octet X se répétant au moins 3 fols. Décomposons en paires de bits: XA XB XC XD
- la traduction donne pour 3 X consécutifs 3 fois le signe XB XC XD et le signe XA XA XA.
- on constate que si la paire XB ou XC ou XD est différente de XA, alors on n'aura que 3 signes identiques consécutifs, suivis d'un différent.
- par contre, si XB=XC=XD=XA, alors les 4 signes sont identiques. Dans ce cas une longue suite d'octets identiques produira une d'autant plus longue suite de signes semblables.
L'être humain ne pouvant dénombrer plus de 4 ou 5 choses au coup d'œil. Il est plus confortable d'empêcher l'apparition d'une telle suite. C'est pourquoi la ligne DATA, après création de la suite de 24 signes, subit un compactage: tout bloc d'au moins 4 signes Identiques est réduit en un bloc de 3 signes:
"." = Indicateur de bloc compacté. "-" = signe constituant le bloc "-" = signe codant la longueur du bloc
Ainsi le point "." n'apparaît que dans une ligne où il y a eu compactage. Comme dans ce cas la longueur de la ligne est réduite on la repère aisément par rapport aux autres de longueur standard ( cf le listing de LOCAL.BAS). Un dernier paragraphe pour détailler le contrôle d'Interversion. Le minimum pour détecter les erreurs dans une suite de DATAs est la somme de contrôle. Qu'un signe soit changé, et il y a détection (l'erreur peut être d'ailleurs dans la somme de contrôle). 2 erreurs ou plus peuvent se compenser mais c'est assez Improbable. Par contre la somme de contrôle ne peut détecter l'Interversion de 2 signes, qui est pourtant très courante. Pour y pallier, il faut un contrôle d'Interversion. La méthode que J'emploie est fondée sur ces observations: 1-"L'interversion de 2 signes identiques ne se volt pas." 2-"2 signes différents sont ordonna-blés."
C'est-à-dire qu'entre 2 signes quelconques, on peut établir une relation d'ordre du type "Inférieur" ou "supérieur"; on attribue au choix l'égalité à "Inférieur" ou "supérieur", du fait de l'observation 1. Il suffit de 2 signes différents pour coder une suite de relations d'ordre. Par exemple on prendra "0" pour "inférieur" et "1" pour "supérieur" ou "égal". On obtient alors une suite de 0 et 1. Hors, 0 et 1 sont les chiffres de la base 2. Ainsi on peut établir une équivalence entre la suite de relations d'ordre et un nombre, exprimé en une base quelconque. Pour des raisons pratiques, on choisira la base 16. Voyons un exemple: suite de signes: AsF8GGhRt A>s: 1
s<F:0
F>8:1
8<G:0
G=G:1
G>h:1
h<R:0
R>t: 1 nombre binaire &X10101101 = nombre hexadécimal &AD Que 2 signes soient Intervertis, alors une relation d'ordre change. Un 1 est alors remplacé par un 0 ou l'inverse. Le nombre calculé diffère alors automatiquement du nombre de contrôle d'interversion originel. Pour 24 signes cela fait 23 comparaisons, donc un nombre binaire sur 23 chiffres. En hexadécimal, cela fait 6 chiffres. Plutôt que de les placer en fin de ligne. Je les al mis au milieu, afin de couper la séquence de 24 signes (maximum s'il n'y a pas de compilation); cela facilite la lecture. En tout et pour tout on a une ligne de DATA comportant 24 signes de codage (au plus) + 6 chiffres hexadéclmaux + 2 virgules pour encadrer le nombre ainsi formé: total de 32 caractères (au plus). Par rapport à une ligne classique remplissant la même fonction, on gagne avec ce système un tiers de place, alors que sont inclus une somme de contrôle et un contrôle d'interversion, absents du système classique. On voit donc tout l'Intérêt de la méthode. CQFD.
Maintenant que la méthode est expliquée. Il n'y a plus qu'à la mettre en pratique. Passons aux programmes! CONVERSION DE
BINAIRE EN DATA
COMPACT Ceci est l'œuvre du programme COMPADAT. Il est suffisamment commenté pour qui maîtrise un minimum la programmation. Il suppose le code déjà en mémoire, mais pas de problème pour l'y faire charger par un LOAD dans le programme. COMPADAT est entièrement paramétré en lignes 280-300 (Remarque: COMPADA2 est Identique à COMPADAT pour le fonctionnement; les commentaires ont disparu et les instructions ont été mises sur un minimum de lignes).
Les grandes étapes sont: - création de la liste des 64 signes, calcul du nombre de lignes DATA générées en fonction de la longueur "Ion" du code: c'est "ni".
- Lecture par pack de 15 octets, formation du dernier bloc de 3 octets en ajoutant les octets de la somme de contrôle à la suite du 16ème octet traitement du pack de 18 octets ainsi formé: lecture par blocs de 3 octets, traduction en bloc de 4 signes, calcul du contrôle d'interversion, compactage éventuel de la ligne de signes, création de la ligne DATA, affichage de cette ligne et écriture dans le fichier ASCII de sortie
- continuer Jusqu'à la dernière ligne, fermer le fichier de sortie
Il ne reste plus qu'à fusionner le fichier ASCII de sortie avec le convertisseur de DATA en binaire pour obtenir son chargeur de DATAs. CONVERSION DE DATA COMPACT EN BINAIRE  Ce programme est le pendant de COMPADAT et consiste à convertir les DATAs compacts en code: il s'agit de DATABIN. Encore une fois il est très largement commenté. A priori, pour le lecteur moyen juste Intéressé par le fait de taper un chargeur de DATAs, pour le lancer et avoir du code exécutable, peu importe son fonctionnement, du moment que cela marche. Ainsi DATABI2 est-Il Identique à DATABIN, hormis l'absence de commentaires et la réduction à un minimum de lignes. Pour ceux qui ont quelque curiosité, voyons-en rapidement les étapes: - création de la liste des 64 signes, calcul du nombre de lignes DATA générées en fonction de la longueur "Ion" du code: c'est "ni".
- lecture ligne par ligne, décompactage éventuel de la suite de signes, lecture par blocs de 4 signes, traduction en bloc de 3 octets, poke des 16 octets
- vérification somme de contrôle, contrôle d'interversion
- continuer jusqu'à la dernière ligne, sauvegarder le code
Ce programme est pourvu d'Information en temps réel pour suivre son bon déroulement: affichage du numéro de ligne et des DATAS, ainsi que du pourcentage du traitement effectué (cf LOCAL.BAS à l'éxecution). Attention à bien assigner aux variables "nol" et "pas" le premier numéro de ligne DATA et l'Incrément de numéro. Cette traduction en code est naturellement moins rapide que l'habituelle, les opérations de conversion étant plus complexes. Ce n'est toutefois pas une gêne, la conversion de DATAs en code étant généralement effectuée une fols pour toutes.
Voyons maintenant ce que cela donne concrètement. Démonstration par l'exemple! 
PROGRAMMES DE DEMONSTRATION LOCAL.BAS En Janvier 1991 CPCinfos a publié mon programme d'implantation de RSX permettant l'usage de variables locales et donc de récursivité sur CPC et sous BASIC. Ces RSX sont STACK, LOCAL, ENDLOCAL, GIVE et GET. Pour plus d'information et pour des exemples, consultez les numéros de Janvier et Mars 1991. Je propose à nouveau ce programme, mais amélioré: Je mets évidemment en application ma méthode de création de DATAs compacts en vous proposant un nouveau chargeur BASIC (Il s'agit de LOCAL). Et Je mets aussi en application ma méthode pour l'écriture d'un "programme machine exécutable à toute adresse de chargement" et que j'ai d'écrite dans mon article «BSTACK" publié dans CPCinfos de Juillet 92 (no 46). Il s'ensuit donc que le fichier binaire LOCAL.RSX peut être chargé n'importe où (en mémoire centrale pour cause d'accès aisé aux RSX). De plus le code reconnaît de lui-même la version du CPC où II doit tourner (464, 664 ou 6128) à chaque installation des RSX. Pour la première version de Janvier 1991, il était adapté lors de la conversion des DATAs en binaire au type de CPC sur lequel il était traduit (cela concerne l'appel en ROM Basic pour générer un message d'erreur). Plus de souci maintenant de ce côté-là.
Enfin, à titre d'information, les 160 premiers octets du code ne sont plus utiles une fols les RSX installées. Ils concernent en effet l'adaptation du code à son adresse de chargement, la détermination du type de CPC et la mise à jour du saut en ROM pour une erreur en fonction de ce type et finalement l'installation des RSX. La place qu'ils occupent peut donc être employée après l'appel d'initialisation. PAL-OCP & PALOADER Je suppose que qu'il est arrivé à beaucoup de travailler avec OCP Art Studio un écran venu d'ailleurs (d'un Jeu, d'un fanzine, d'un autre utilitaire de dessin...). Une chose fastidieuse est de créer la palette de couleurs, surtout en mode 0. Il faut en fait se débrouiller pour lire auparavant les valeurs des encres et les noter. Puis, sous OCP, Il n'y a plus qu'à (!) se fendre de réglages de curseur avec PALETTE. Le faire pour 1 écran de temps en temps est supportable. Mais dès qu'il y en a seulement 2 ou 3 ou plus, cela devient du travail forcé.
Confronté une fois à cela, je me suis penché sur la question: ayant constaté cette évidence, à savoir qu'un écran affiché par un jeu, un fanzine, un utilitaire, etc.. l'est dans le bon mode et avec les bonnes couleurs, l'idéal serait de sauvegarder juste après l'affichage le mode et les couleurs au format du fichier PAL de OCP Art Studio. 
Après quelques dizaines de minutes passées à observer un tel fichier PAL et surtout à cogiter et programmer, j'ai obtenu mon petit utilitaire si pratique: PAL-OCP. Toutes les explications sont contenues dans PAL-OCP.BAS qui Installe la routine. Le fichier au format PAL est créé en mémoire; c'est à l'utilisateur de le sauvegarder sous le nom "nomdécran.PAL".
Pour mettre en œuvre tout cela, taper PAL-OCP.BAS et le sauvegarder. Taper PALOADER et le lancer: Il sauve le fichier binaire PAL-OCP.BIN, installé par PAL-OCP.BAS. Bonnes récupérations d'écrans ! CONCLUSION J'espère faire des émules parmi tous ceux qui proposent leur œuvres binaires à CPCinfos. Rien que le contrôle d'interversion serait intéressant à généraliser. Comme le client est roi. Il peut toujours écrire à CPCinfos pour plébisciter ce nouveau type de chargeur de DATA ou alors pour signifier son refus de la chose. Quoi qu'il en soit cela peut donner des Idées à certains, comme le cryptage de données. L'imagination est reine dans le domaine de la programmation. A une prochaine fois ! Yannick GOUR , CPCinfos
| ★ AMSTRAD CPC ★ DOWNLOAD ★ |
 | Aucun fichier de disponible:
» Vous avez des fichiers que nous ne possédons pas concernent cette page ? | | ★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser... |
CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 428 millisecondes et consultée 1866 foisL'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. |
|
|
|
