AMSTRAD CPC : je découvre une curiosité!

[@Stab1l0b0ss]

C'est parfaitement logique, il n'y a pas de mode texte sur CPC. Ce que vous pouvez aussi remarquer, c'est que si vous copiez un caractère qui existe (shift+touches flechées+copy), il agit comme vous l'avez justement décrit dans votre vidéo. Mais si vous tentez de copier un caractère qui n'existe pas, il ne le trouvera pas dans la table des symboles, et refusera de copier quoi que ce soit en faisant le BIP caractéristique du basic. Pour compléter votre vidéo, ce qui est également remarquable, c'est que pour trouver le caractère correspondant, le CPC parcourt donc la table des symboles en ROM, et change de table à partir du premier symbole redéfinissable (SYMBOL AFTER, par défaut 240) pour parcourir la table des caractères redéfinis, et cette table est en RAM. C'est de loin le plus efficace, propre et souple des BASIC 8 bits.

[@retrovynz8712]

Merci pour cet approfondissement!

[@stephanesikora]

@@retrovynz8712 Oui comme le dit Golem, c'est le comportement du vecteur &BB60 du firmware de l' Amstrad CPC. J'ai écrit un petit billet qui décortique ce qui se passe dans la ROM quand on utilise la touche Copy. Hélas je ne peux pas poster le lien ici, sinon mon message sera effacé !

[@Neotenien]

Ca ferai pareil avec des ordinateurs ayant un mode "caractère" (comme sur les Thomson), En fait suir les Thomson, le mode caractères est juste le mode vidéo TO7 qui a la RAM A pour les "formes" et la RAM B pour les "couleurs". Donc en somme, ça marche pareil sur Thomson.

[@falmircamion3534]

Tout ça est d'ailleurs documenté dans les bouquins de la machine, en fait. ça m'a d'ailleurs surpris, quand j'ai eu mon premier compatible PC quelques années après, de découvrir qu'il y avait un mode texte et un mode graphique distincts. 😅

[@letouristedunet3921]

David Goodenough, développeur chez Amstrad en 1983 : "Bon allez, ça va passer..."

[@retrovynz8712]

🤣🤣🤣

[@natsuslayer1]

Est ce que vous avez déjà vu un fantôme clignoter ?

[@berquezcarl-stephane3860]

C'est tout à fait logique car le CPC n'a pas de mode caractère donc en toute logique il vérifie la table des caractères depuis le début pour s'arrêter sur la première occurence, en l'espèce le 157.

[@retrovynz8712]

Voilà. J'en suis arrivé à cette conclusion, mais j'avais un peu peur des réactions en disant "le CPC n'a pas de mode caractères!", ce qui explique sa lenteur à l'affichage lorsqu'on fait un LIST par exemple.

[@letouristedunet3921]

@@retrovynz8712 Amstrad a inventé le scanner QR code sans le savoir...

[@Neotenien]

@@letouristedunet3921 Euh non!! Ca existait déjà sur les Thomson TO7 en 1983 et sans doute d'autres avant. A voir les ordinateur dont le copro graphique ne gérait pas de mode Texte en Hard.

[@xavier_le_x]

Bah y a rien d'anormal c'est logique Il sait parfaitement ce qu'il affiche. Tu lui donnes une modif du 206 vers 157 Il a une liste de caractères et il tombe sur 157 en 1er. Il n'affiche donc que 157. Ce qui est correct. Je ne vois aucun bug

[@lariost5683]

Ce qui est marrant, c'est que le choix qui a été fait est d'éviter de stocker trop d'infos en ROM mais plutôt de perdre du temps à aller rechercher une correspondance visuelle, on va perdre du temps processeur mais voila on va gagner en stockage, c'était la mentalité à l'époque, à des années lumières de celle d'aujourd'hui.

[@MiGaNuTs2]

A l'époque la RAM était précieuse sur les machines. On était bien obligés de l'économiser, sinon c'était le plantage assuré. On avait tout simplement pas les mêmes problématiques, alors forcément on utilisait pas les mêmes stratégies.

[@rabdanely]

C'est normal. Vous avez juste copié à l'écran le même graphique dans A$ et B$. Comme vous avez modifié en mémoire l'ASCII 157 pour qu'il soit comme 206, alors il vous répond que les caractères copiés à l'écran ont les mêmes codes ASCII. En l'occurrence 157 que vous avez modifié.

[@Neotenien]

Salut Vincent, en quoi ceci est une "surprise" comme tu dis ? Le Basic n'établit pas une "table" du contenu de l'écran... Tu dis que les autres ordi 8 bits ne font pas ça, mais je pense que les Thomson font pareil (je testerai ça demain, sachant que pour les Thomson, ça ne compare que les 128 premiers octets car la table des autres sont dans un autre espace mémoire. En plus ya les caractères accentués pour lesquel le code est différent (2 caractères). Ce que fait ton amstrad là est complètement logique!! Il compare la suite de 8 octets à l'écran à pârtir d'une position "texte" en comparant les série de 8 pts (pixel éteuins ou alumés, soit 1 octets) avec les suite de 8 octets coresponda à la table d'allocation de caractères. Qu'imaginais-tu qu'il ferait d'autre ? En tous cas, j'essaierai demain pour voir si ça fait pareil avec les Thomson.

[@retrovynz8712]

C'est logique oui mais on n'y pense pas de prime abord lorsqu'on utilise la fonction Copychr$. On aurait tendance à croire le manuel original de l'Amstrad CPC qui indique clairement "copie le CARACTÈRE...". Ce qui est faux. Je me suis dit qu'il était utile, pour les autres utilisateurs du Basic, de bien avoir cela à l'esprit car c'est une sérieuse source d'erreurs à contrôler dans un programme qui utiliserait cette instruction.

[@davidcroquette8578]

En meme temps si le caractère 157 et identique au 206… Pourquoi irait chercher une occurrence au 206 en ayant trouvé une au 157 😏

[@retrovynz8712]

parce que tu peux vouloir avoir plusieurs caractères d'aspect identique mais qui réagissent différemment lorsqu'ils sont rencontrés. Même si en réalité il vaut mieux utiliser des tableaux plutôt que de tester ce qui est en mémoire video qui n'est d'aucune fiabilité en matière de caractères puisque c'est uniquement du bitmap qui est représenté.

[@roucoupse]

Et si après copychr$ (ou juste avant), les caractères sont à nouveau modifiés, qu'est-ce que cela donne, il renvoie quoi comme code ascii puisque cela ne correspond plus à rien dans la table de caractères ?

[@retrovynz8712]

Ah! Très intéressant, je testerai. À mon avis il renvoie zéro. Autre chose à tester: Dessiner graphiquement (par des PLOT par exemple), l'équivalent graphique d'un caractère et lire cette portion d'écran avec Copychr$. À mon avis il croira qu'il y a un caractère. D'ailleurs ce truc pourrait être exploité dans des jeux. Ça permettrait de comparer une portion d'écran graphique d'un coup avec un résultat à obtenir consigné en caractères redéfini...

[@roucoupse]

@@retrovynz8712 Oui avec des PLOT il devrait retrouver un caractère en suivant la logique de ta vidéo mais ce serait effectivement bien de s'en assurer également. Et même pourquoi pas essayer aussi avec des PLOT sans aucune redéfinition de SYMBOL pour voir si il traite de la même façon les caractères non modifiés de la ROM car je crois que SYMBOL AFTER 32 duplique les caractères de la ROM dans la RAM. Peut-être que je raconte n'importe quoi je ne suis plus dans l'informatique depuis longtemps.

[@Neotenien]

Ca fera comme sur les Thomson qui ne teste que les 128 premiers caractères de la tabkle asci, c'est à dire que ça ne renvoie rien (j'ai déjà testé ça, avec des GR$(n) affiché à l'écranet ça ne donnait rien).

[@thomo5]

Vraiment intéressant, mais j'ai vraiment du mal à comprendre pourquoi le BASIC fait l'erreur, du coup à voir sur d'autres micro, si cela se produit aussi.

[@retrovynz8712]

Parce qu'en fait, contrairement à la description de la commande Copychr$ qui est faite dans le manuel, celle-ci ne copie pas le caractère affiché mais une portion d'écran de 8x8 pixels. Car ce sont les pixels de l''écran qui sont consignés en RAM et non les caractères. En d'autres termes, le CPC n'a pas de mode texte, il est purement graphique.

[@Neotenien]

C'est complètement logique! Et ça ferait pareil sur Thomson, je ne vois pas comment il en serait autrement. Il n'y a PAS d'espace RAM indiquant que tel ou tel caractère est positionné sur l'écran. Une fois que c'est affiché, c'est la RAM écran qui contient les pixel "allumés" ou "éteinds". Ca n'est PAS une erreur! Et 'est pareil sur tous les ordinateurs 8 bits! (voire même 16 bits et au delà)

[@retrovynz8712]

@@Neotenien Alors, non, Bruno, ce n'est pas pareil sur tous les ordis. Un ordi qui a un mode texte, et qui enregistre en mémoire écran le numero ascii des caractères, que l'on voit affichés donc, ben si tu interroges sa mémoire écran, soit par un Peek, soit par une commande du style copychr$, il va te renvoyer le bon numéro ascii et ce, même si tu as des doublons graphiques.

[@Neotenien]

@@retrovynz8712 Bon faux que j'essaie sur Thomson, mais je pense que ça va donner la même chose... Enregistrer les codes ascii sir écran, ça prendrait pas mal de place quand même (40x25 = 2000 caractères, voire plus)

[@Neotenien]

@@retrovynz8712 Euh, un PEEK sur mémoire écran ne renverra qu'un code correspondant soit à une couleur, soit un GPL, soit une combinaison des 2 (pour le Thomson, ça dépend des modes écran, mais en AUCUN cas on aura une lettre, puisqu'une lettre prend 8 ou 4 octets suivant les modes!)