Posté le 05/05/2020 16:04
!!!
), comment pourrait-on obtenir la valeur hexadécimale d'un caractère créé, par exemple le fichier joint (en 6*8) ? Est-ce possible ? 
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 112 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 05/05/2020 18:24 | #
Comme on l'a dit, le binaire et l'hexa ne sont que deux faces de la même chose, tout éditeur hexa décent t'affichera le binaire.
Mais prends l'habitude de bosser avec l'hexa si tu peux, parce que personne ne s'embête à écrire le binaire complet sauf pour faire des images. C'est pas assez compact.
Citer : Posté le 05/05/2020 18:28 | #
J'ai remarqué
J'y veillerais. Encore beaucoup merci !!
Ajouté le 05/05/2020 à 19:24 :
Logiquement, l'OS devrait contenir le "code binaire" de la lettre 'A', n'est-ce pas ?
C'est à dire" 01110000 10001000 10001000 11111000 10001000 10001000 10001000" (merci Lephenixnoir) ?
Citer : Posté le 05/05/2020 19:33 | #
Si je me suis pas planté sur l'encodage, alors oui.
Ajouté le 05/05/2020 à 21:13 :
Il y a une table des bitmaps qui a été extraite en fait, j'aurais dû m'en douter : https://forge.touhey.org/casio/fontcharacter.git/tree/reference/normal
C'est Cake qui me l'a rappelé, mais pour citer sa réponse quand j'ai voulu le faire poster ici :
En fait non, j'ai pas les couilles de m'auto-citer
Ajouté le 05/05/2020 à 21:18 :
Lecture complémentaire : https://thomas.touhey.fr/2018/07/11/characters.fr.html
Citer : Posté le 06/05/2020 10:02 | #
Mais du coup, comment est codée la lettre 'A' dans l'OS (en binaire) ?
Parce que je trouve pas la longue suite de 0 et de 1 dans l'OS
La "table de bitmaps extraite" coderait la lettre 'A' d'une façon particulière ? (je m'acharne depuis ce matin à essayer de bien comprendre de fond en comble ton 1er lien, mais mon cerveau a disjoncté
Citer : Posté le 06/05/2020 10:12 | #
Comme je l'ai mentionné, il faut différencier :
• La lettre A, dont la valeur est 65
• Le bitmap de la lettre A, dont la valeur est donnée par l'encodage que j'ai décrit ci-dessus
Dans l'OS, chaque fois qu'une ligne de texte contient la lettre A, il y a un octet de valeur 65 = 0x41. Attention évidemment, il y a plein d'octets de cette valeur qui sont autre chose que des A.
Citer : Posté le 06/05/2020 10:18 | #
Alors comment l'OS fait-il pour différencier le même octet (de valeur 65 = 0x41) plusieurs fois ?
il ne peut pas valoir quelque chose de différent s'il ne change pas.
Il ne peut pas valoir le bitmap de la lettre 'A' une fois, puis autre chose une autre fois ...
Citer : Posté le 06/05/2020 10:25 | #
Tout est une question d'interprétation. Si je fais afficher_caractère(65) ça donne un A. Si je fais lancer_application(65) ça lance l'application numéro 65 et ça n'a rien à voir avec une lettre.
Il faut comprendre que les données dans l'OS ne sont que des données. Les 0 et les 1 tous seuls n'ont pas une étiquette disant "je suis un caractère dans un texte" ou "je suis un numéro d'applications". C'est l'OS qui est codé pour afficher certaines données comme du texte et considérer d'autres données comme des numéros d'applications. Si tu écris 'A' ou 65 dans un programme C, tu obtiens exactement la même chose : un entier de valeur 65. Dans le code on voit la différence parce que c'est écrit différemment, mais une fois compilé on ne voit plus la différence, il n'y que deux entiers de valeur 65.
Encore une fois, 65 c'est le code ASCII de la lettre A, pas le bitmap de la lettre A. Le bitmap de la lettre A est encodé dans l'OS par 70 88 88 f8 88 88 88 (en hexa).
Citer : Posté le 06/05/2020 10:35 | #
Si tu ne le vois pas c'est peut être un problème d'endianness ? Faudrait essayer de swapper les paires de 2 octets, voir juste inverser le tout (je comprends jamais rien à ces histoires d'endianness :/)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 06/05/2020 10:37 | #
Bien pensé, mais y'a aucun problème d'endianness vu qu'on cherche des octets individuels dans des tableaux.
L'endianness, c'est l'ordre des octets pour les valeurs composées de plusieurs octets : les entiers de 2 ou 4 octets et les pointeurs en gros. L'ordre des éléments d'un tableau ne change pas. Et comme les caractères ne font qu'un seul octet et que le bitmap est "fortement ordonné" il n'y a aucun risque de changement.
Citer : Posté le 06/05/2020 10:40 | #
Merci pour vos explications.
Je suis peut-être nul, mais je ne trouve pas "70 88 88 f8 88 88 88" dans l'OS (représenté sous forme hexadécimale, bien entendu)
Du coup, je pense que je vais abandonner le projet
Citer : Posté le 06/05/2020 10:49 | #
Il suffit de chercher un peu. Sur le topic de Remiweb :
- un caractère fait 6x8 pixels, la colonne de gauche et la ligne du bas étant vides pour la plupart des caractères.
- chaque ligne de pixels du caractère est codée sur un octet
- les deux derniers bits de cet octet sont inutilisés, donc des 0
Donc il est possible que les bits inutilisés ne soient pas exactement à l'endroit donc je me souvenais (ce qui change la valeur des octets dans l'encodage).
De plus il y a toujours le syscall 0x136 qui va te donner directement l'adresse du glyphe sur ta version de l'OS, il suffira alors d'aller le lire pour connaître l'encodage exact.
Citer : Posté le 13/05/2020 11:17 | #
Houla houla ! On sort du domaine du facile, là...
Hélas, ton syscall 0x136, moi, je connais pas.
Et j'ai peur de ne pouvoir comprendre la moindre chose, même avec les supers explications d'un professeur très doué.
Et du coup, quelqu'un pourrait-il se baisser à la hauteur de mon pauvre cerveau et me dire de la manière la plus claire possible de quelle manière est codée le bitmap représentant la lettre 'A' dans l'OS (en binaire) ?
Parce que ( oui, ce n'est pas normal ) je ne trouve pas " 01110000 10001000 10001000 11111000 10001000 10001000 10001000" (merci Lephenixnoir)
Je suis désolé pour ma magistrale incompréhension à vos réponses qui, à une autre personne que moi, auraient sûrement déclenchées un torrent de remerciements pour leur clarté. Malheureusement, c'est ainsi, je ne suis pas doué.
Ajouté le 13/05/2020 à 11:18 :
Merci d'avance
Citer : Posté le 13/05/2020 11:31 | #
C'était l'encodage de mémoire, mais les informations de Remiweb permettent de corriger mon erreur. Les caractères font 6x8 et chaque ligne est encodée sur un octet. Il y a donc deux bits inutilisés sur chaque octet. Par contre, je croyais que les caractères de 5x7 étaient en haut à gauche de la boîte de 6x8, or ils sont en haut à droite. Remiweb indique sur son topic :
- un caractère fait 6x8 pixels, la colonne de gauche et la ligne du bas étant vides pour la plupart des caractères.
- chaque ligne de pixels du caractère est codée sur un octet
- les deux derniers bits de cet octet sont inutilisés, donc des 0
Le nouvel encodage du bitmap de A est donc le suivant :
01000100 = 0x44
01000100 = 0x44
01111100 = 0x7c
01000100 = 0x44
01000100 = 0x44
01000100 = 0x44
00000000 = 0x00
Dans la version 3.10 de l'OS pour Graph 35+E II, je trouve facilement cette valeur :
00247440: 1000 1000 3844 0434 5454 3800 3844 447c ....8D.4TT8.8DD|
00247450: 4444 4400 7844 4478 4444 7800 3844 4040 DDD.xDDxDDx.8D@@
00247460: 4044 3800 7048 4444 4448 7000 7c40 4078 @D8.pHDDDHp.|@@x
Ici à l'adresse 0024744c, 8 octets. On voit d'autres caractères autour, par exemple celui d'avant est 3844 0434 5454 3800, ce qui donne :
0x44 = 01000100
0x04 = 00000100
0x34 = 00110100
0x54 = 01010100
0x54 = 01010100
0x38 = 00111000
0x00 = 00000000
C'est le caractère @, ce qui n'est pas surprenant car il précède A dans l'encodage utilisé par la calculatrice (qui est une extension d'ASCII).
Désolé pour la confusion, j'ai juste répondu un peu vite sur la question de l'encodage, je pensais pas que ça poserait autant de problèmes.
Citer : Posté le 13/05/2020 11:50 | #
AAAh
Alors là merci vraiment super beaucoup !
Il me semble enfin avoir un peu compris
Ajouté le 13/05/2020 à 11:50 :
Nan mais vraiment, là, c'était super clair!!!
Encore merci !!
Ajouté le 13/05/2020 à 12:01 :
Et j'ai trouvé cette fois-ci !
Super !
[ vocabulaire varié ]
Citer : Posté le 13/05/2020 12:52 | #
Excellent, bon courage pour la suite !
Citer : Posté le 13/05/2020 13:14 | #
ZZ m'avait dit que c'était dangereux, la modif de Remiweb.
Un flingage total de la calto est-il à redouter ?
Citer : Posté le 13/05/2020 13:19 | #
Il faut savoir un peu ce que tu fais : ne modifier *que* les octets correspondant à des bitmaps encodés, et ensuite bien recalculer les checksums avec polyOS ou quelque chose du genre.
Tant que tu ne modifies rien d'autre que ces octets-là, aucun flingage de la calto n'est à redouter.
Mon conseil : avant tout flash, utilise un éditeur hexadécimal pour obtenir un diff de ton OS par rapport à l'original, et vérifie que tu n'as modifié que la région avec les caractères, et les checksums.
Citer : Posté le 13/05/2020 13:56 | #
Ah ! Ça me rassure
Bon, je vais essayer avec ta méthode.
À bientôt !
Citer : Posté le 13/05/2020 14:23 | # |
Fichier joint
Ca a marché !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
J'ai remplacé un caractère chelou par ff ff ff ff ff ff ff ff, à l'aide de fx-Remote, j'ai balancé su ma calto, et... OUAIIIIIIIIIIIS !!!!!
Ca m'a donné un caractère plein !
C'est vraiment super trop génial !
merci à Zezombye, et surtout à Lephenixnoir pour toute leur immense aide !!!
Je ferais bon usage de cette technique, soyez-en assurés
Les captures ont été faites à l'aide du Screen Receiver, mais quelqu'un connaîtrais un logiciel qui prend une vidéo de la calto, et pas juste des photos ?
Citer : Posté le 13/05/2020 15:25 | # |
Fichier joint
Problème résolu avec une capture de tout le PC
Citer : Posté le 13/05/2020 15:36 | #
Comme Remiweb du coup ! Bien joué !