Shrinkler sur CPC!

Roudoudou a récemment réalisé le portage de la routine de décompression de « Shrinkler », un compresseur très performant,  sur Z80. Il explique lui même sur Memoryfull les détails de ce portage, et propose une comparaison avec les autres crunchers.

Shrinkler fait partie de la famille des crunchers  qui offrent un niveau de compression très élevé, mais au prix d’un temps de décompression important (environ 5 secondes par kilo-octet de données crunchées). Il faut donc l’utiliser à bon escient! De plus, il a été conçu pour optimiser le code assembleur des processeurs de la famille des 68000. Il n’est utilisable sur CPC qu’en mode ‘data’. Ceci étant dit, c’est donc un outil idéal pour vos futures productions 4KB!

Je vous propose ici un rapide tuto, avec rasm (c’est donc un article très roudoudou-compatible!), dans lequel on va tester la routine de décompession de shrinkler sur CPC! Nous allons compresser une image, ce qui n’est pas forcément le bon usage, mais comme cela ce sera bien visuel. On pourra en particulier constater que la décompression prend un peu de temps… On va donc partir d’un ficher de 16KO a compresser. avec comme adresse de départ #C000, l’adresse de la mémoire vidéo par défaut sur CPC.

Compression

La routine peut être trouvée ici. L’archive contient le fichier original de Roudoudou, mais aussi des version optimisées, dont celle de Madram.

Commençons tout d’abord par compresser le fichier. Ca se passe sur PC, par exemple sous linux ou windows, avec une commande de la sorte (merci Tronic pour m’avoir indiqué les options d’optimistion supplémentaires!) :

shrinkler -d -p -9 inputfile.bin crunched.bin
  • -d pour le mode data
  • -9 pour augmenter le niveau de compression au maximum

Pour l’exemple, j’ai utilisé le splash screen de Ghost’n’Goblins, qui passe de 16Kb à 8672 octets, une fois compressé.

Décompression

Les macros pour sauvegarder/restaurer les registres mirroirs sont dans le fichier ‘toolbox.asm’, dont voici le contenu:

Maintenant si l’on recommence l’opération, mais en visualisant la mémoire qui commence à l’adresse #4000

out &bc00,&0c
out &bd00,&10

Fantaisie en passant

Maintenant que la fine fleure des CPCistes a optimisé au maximum le code de décompression, il est temps d’y ajouter notre grain de sel, d’alourdir leur code, mais pour une bonne cause: en effet, attendre une quinzaine de secondes sans qu’il ne se passe rien à l’écran est passablement long et ennuyeux. Au prix de quelque octets et d’un léger ralentissement, il est possible d’agrémenter ce moment d’une animation minimaliste, qui détournera le spectateur de son impatience maladive.

Dans la routine de décompression, la boucle qui a pour label ‘literal’ est appelée quelques fois par trame vidéo. On peut y insérer son propre code a ce niveau, en prenant bien soin de sauvegarder les registres que l’on va utiliser. On pourrait écrire dans la mémoire vidéo (faire une barre de progression par exemple), mais en l’occurrence comme on décompresse une image, on va se contenter de changer les couleurs du bords:

Pas de commentaire particulier sur ce bout de code, si ce n’est que la valeur du registre C est utilisée pour décider de la couleur. Cela évite d’utiliser par exemple le registre R pour obtenir une couleur pseudo aléatoire. Par ailleurs, quelques symboles sont utilisés:

GA_PORT:           EQU #7F00
GA_SELECT_BORDER:  EQU #10
GA_SET_COLOR:      EQU #40

Dans la version ‘madram’ on pourrait aussi utiler H ou IXL au lieu de C pour avoir une couleur qui change de facon moins aléatoire.

Liens

 

mai 30, 2018

  • À noter que la routine à encore été optimisée par madram! Voir dernière version sur le topic cpcwiki (lien sur memory full)