THOMSON MO6 BASIC 128 GET/PUT

[dinoprodest]

Bonjour, J'ai remarqué que l'instruction Get stocke les couleurs dans un étrange format binaire :
BFFF FBBB
7654 3210
Où B est la couleur d’arrière-plan et F est la couleur de premier plan. Quelqu'un peut-il m'expliquer pourquoi ?

[__sam__]

Oui c'est l'encodage "TO" qui semble complètement irrationnel, mais qui s'explique pour des raisons historiques.

Initialement le TO7 n'avait que 8 couleurs, et la RAM vidéo "couleur" n'avait que 6 bits. L'octet de fond était encodé comme suit: bvrBVR (minuscule = forme, MAJuscule = fond). C'était logique.

Ensuite est apparu le TO7/70 avec 8 vrais bits pour la mémoire "couleur", donc 16 couleurs. Mais pour rester compatible avec l'encodage TO7 (sur 6 bits), il a été étendu comme suit: PpbvrBVR, avec P et p les bits dits pastels permettant d'accéder aux 8 couleurs supplémentaires. Ils sont à 1 pour les 8 couleurs de base et 0 pour les nouvelles (je crois que "1" était retournée par le bus sur les TO7 quand on lisait l'octet de 6 bits). Il s'agit donc du complément à 1 (inversion) du bit de poids fort des numéros de couleurs. C'est donc cet encodage là qu'on retrouve dans le format des fichiers MAP apparus à la même époque. Il était compatible TO7 et TO7/70.

Coté MO, ils ont eus des le départ 8 bits pour la ram "couleur" et n'ayant pas de compatibilité ascendante avec le matériel, ils ont optés pour un encodage plus adapté aux 16 couleurs: prvbPRVB (avec p/P pas inversé contrairement aux TO). Cependant pour garder la compatibilité avec les fichier MAP déjà compatibles TO7 et TO7/70, les routines de PUT/GET du basic sur les MO6/PC128 doivent réaliser un transcodage "TO->MO" de l'octet couleur des fichiers MAP. C'est un peu plus lent, mais marginal en pratique sur la vitesse d'affichage d'une image dans ce format.

[dinoprodest]

merci beaucoup Sam, Pouvez-vous m'expliquer pourquoi lorsque vous stockez une image avec Get, l'emplacement $2145 contient le pointeur vers la matrice et $2147 la banque. Mais dans certaines situations, le croupier ne correspond pas et est déduit de 1.

[__sam__]

Je ne connais pas bien le MO6, mais sur TO, les instructions GET/PUT stockent les images dans des tableaux d'entiers. Il y a donc des histoire d'alignement pour que la longueur des données soit paire: un 0 peut être ajouté en fin de fichier/zone mémoire. C'est peut-être cela qui entre en jeu dans ce dont tu parles.

Curieusement la documentation de l'extramon MO6 ne parle pas des adresses $2145-$2147 mais plutot de $216B-$216D:

Capture.PNG (109.4 Kio) Consulté 313 fois

Capture.PNG (165.59 Kio) Consulté 313 fois

La zone $2145-$2147 est proche de l'accumulateur de l'extramon pour les calculs arithmétiques:

Capture.PNG (152.31 Kio) Consulté 313 fois

On peut donc supposer que c'est une adresse réservée au basic. Comment l'as tu obtenue ?

[dinoprodest]

J'ai découvert $2145/46 et 2147 par hasard avec le débogueur. Il semble qu'ils contiennent l'adresse et la banque de mémoire de la dernière variable utilisée par basic. Je vais maintenant essayer les adresses de la documentation que vous m'avez envoyée, c'est peut-être plus approprié pour mon objectif.