Bonjour à tous,
J'aimerai partager avec vous une réflexion sur l'affichage écran du ZX81.
Présentation du ZX81:
Le Zx81 est un ordinateur muni d'un Zilog (clone du 8080) avec 1k octets en version de base.
La rom de 8K possède un basic qui gère une taille mémoire de 16k maximum (limitation constructeur). Il est à noter que Sinclair n'a JAMAIS fabriqué ou fait fabriquer d'extension mémoire supérieur à 16k, de peur que les utilisateurs ne lui reproche cette limitation due au test mémoire de la ROM !
L'affichage est simple, et ne possède pas d'UDG (redéfinition graphique), mais une police de caractère de 63 symboles (alpha et graphique).
Cette police de caractère peut être affichée en vidéo inversé en activant le bit 7 à l'affichage.
Le Bit 6 des caractères n'est utilisé qu'en basic pour afficher les commandes et les fonctions Basic.
Le Zx81 a la particularité d'avoir sa mémoire vidéo juste après le programme Basic, ce qui rend son emplacement "flottant", imposé par la taille du programme basic!
Mais une valeur D_File système permet de connaître la valeur de l'offset du premier caractère de la mémoire vidéo.
Pour l'affichage, il suffit de poker directement dans cette mémoire, en évitant de supprimer un caractère de retour à la ligne... fatale au basic, car cela désorganise l'affichage... et fini par afficher le VARS (mémoire des variable, ainsi que le reste de la mémoire, jusqu'en haut des 16k ou se trouve les piles du CPU)...Donc, plantage!
Structure vidéo (16K):
32 caractères + $76 (retour à la ligne)
32 caractères + $76 (retour à la ligne)...
... 24 fois, puis l'on trouve le VARS, où sont stockés les variables.
En version 1k, la rom "compresse" l'écran en éliminant le espaces jusqu'en fin de
ligne:
BONJOUR+$76
$76
$76
... 24 fois
Ce qui permet de ne pas encombrer la mémoire!
Avec une extension mémoire, la taille de la mémoire écran est fixe, avec ses 32 caractère x24 lignes+24 retour à la ligne = 792 octets.
Si l'on veut sauvegarder un dessin, il faut donc 792 octets... ou 768 octets si l'on ne sauvegarde pas les retours à la ligne.
Donc, 16k (16384 octets) peuvent contenir un certain nombre d'écrans... mais combien?
Soit un RAM de 16384 octets:
- 130 octets système.
- 792 octets mémoire vidéo.
- 255 octets pour la pile.
- 2 octets pour les variable (on travail en langage machine)
- 30 octets de Basic.
- 30 octets de langage machine.
= 15145 octets pour les images.
\768 = 19 images plein écran.
L'objet de cette étude est de compresser les images pour que le stockage soit moins gourmand!
Compression par élimination de redondances:
Donc, j'ai encodé les images comme suit:
Soit "XXXXXXAAAAABA..." à l'écran sur la même ligne.
Donc, j'ai 6*"X";5*"A";1*"B";1*"A" = 13 octets.
Vu que le bit6 n'est pas utilisé pour l'affichage, je l'utilise pour "Taguer" le caractère pour indiquer qu'il est répéter * fois.
X!6 A!5 B A (pas de tag pour les lettres non répétées)
Vu que le codage ce fait sur deux octets un DATA et un Multiplicateur, le second est limité à $FF, donc 255 fois.
Un écran blanc (768*" " ou 768*CHR$(0)) est encodé comme suit:
(0 or BIT6) x 255;(0 or BIT6) x 255;(0 or BIT6) x 255
Donc:$40$FF$40$FF$40$FF (6 octets au lieu de 768 octets)
C'est un exemple, car stocker un écran vide est inutile.
Image exemple:
Non codée:
Codée:
Donc, cet encodage évitera les répétitions inutiles.
Tout va dépendre de la complexité de l'image, car si aucune redondance n'est possible, la taille codée et décodée sera identique.
Il est à noter que ce codage ne fonctionne pas avec les données binaires, mais seulement avec les textes, et les images.
Routines ASM et fichier 'P'(compression et décompression sans buffer):
http://zx81.ordi5.free.fr/xavsnap/xpict ... i_zx81.zip
Compression LZ:
On pourrai s'arrêter là, mais j'ai trouvé une routine Z80 pour décoder les fichiers LZ sur Amstrad CPC et Game Boy... Cette routine n'est pas trop lourde et pèse moins de 300 octets... mais permet de réduire les images.
Cette méthode est basée sur le logiciel "PUcrunch" sous PC DOS, et en important les fichiers générés, il est possible de les stocker en mémoire pour une décompression ultérieur.
Pour 16K d'images, je récupère 3K d'espace libre en comptant la routine LZ. (ce qui est non négligeable!)
Routines ASM et fichier 'P':
http://zx81.ordi5.free.fr/xavsnap/xpict ... Z_ZX81.zip
Seul problème, nous avons besoin d'un buffer de décompression pour pouvoir décoder les datas avec le système précédent... donc au pire, 768 octets en moins.
Il serait donc intéressant de décompresser directement en mémoire vidéo, mais cela implique une taille des fichiers compactés "DATAs" plus important qu'avec les deux méthodes de compression.
Routines ASM d'une démo avec pas moins de 30 images en "full screen" et fichier 'P' exécutable sur émulateur:
(seront ajoutées par la suite)
L'ensemble du travail n'est pas encore effectué, mais cela plante le décor pour la suite...
