Comme je l'avais dit ici j'ai pu modifier les caractères de l'OS, j'ouvre donc ce topic pour en discuter
Il est donc possible d'avoir des caractères personnalisés et de les utiliser comme des sprites dans les programmes en basic
Les jeux pourraient simplement avoir une version normale et une spéciale sprites.
Si on arrive à mettre en place un add-in pour gérer ça on peut même envisager des fichiers de sprites qui seraient joints aux jeux.
Mais il reste à voir plusieurs choses :
- Si cela intéresse beaucoup de monde
- Comment procéder (changer l'OS fonctionne, mais à voir avec un Add-in)
- Si c'est faisable, quels sprites intégrer (les créer et se mettre d'accord)
Quelques infos supplémentaire :
Image du 1er essais
Image du 1er essais
Manière dont sont codés les sprites :
Mode texte
Mode texte
- 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
On peut ainsi faire des sprites collables les uns aux autres (pas d'espace entre) comme la pierre sur l'image au dessus.
Mode graphique
Mode graphique
Pour les caractères les moins larges (ex : A,B,C) :
- un octet code pour 2 lignes, on a donc 4 bits par ligne
- un caractère fait 4x6 pixels (on a encore une ligne vide sur le coté et en dessous)
Pour les quelques caractères plus larges (ex: M,Q,W) :
- chaque ligne est codée sur un octet
- un caractère fait 6*6 ?
A vérifier si ça fonctionne bien comme ça pour tous les caractères larges...
Remiweb a écrit : Je ne maîtrise pas du tout ça, désolé si je parle des mauvaises choses
(enfin je sais ce que sont les pointeurs et les syscall mais que en théorie...)
Ok. Un pointeur c'est une adresse dans la mémoire logique (de 0x00000000 à 0xffffffff). Les pointeurs couvrent donc 4 Gio de mémoire, dont on ne dispose bien évidemment pas. La mémoire physique ne fait que 4 Mio et de 256 kio à 512 kio de RAM selon les modèles. Une unité sur la puce, appelée le MMU (pour Memory Management Unit), est chargée de convertir les adresses logiques en entrées dans la mémoire physique pour accéder aux données.
L'OS se trouve à un endroit précis de la mémoire logique (0xa0000000, en fait il est aussi à 0x80000000, mais ce n'est pas une réelle copie : c'est le MMU qui redirige ces deux adresses vers la même zone de mémoire physique où l'OS réside), et on peut y lire, mais pas y écrire. Je peux donc parcourir l'OS en lecture si je veux.
Cependant, l'écriture est plus compliquée. On n'a pas les droits pour le faire avec des pointeurs (le MMU, encore une fois, nous empêche de le faire). Cependant, le système le fait : ne serait-ce que par le logiciel de mise à jour qui écrase toute la zone de mémoire dédiée à l'OS. Cela dit, l'écrasement de secteur ça se passe directement dans la mémoire physique donc on ne sait pas trop où on tape.
Mais maintenant que j'y pense, la gestion de la mémoire de stockage nécessite la modification d'une partie de la mémoire morte (les 4 Mio, donc 2.5 sont dédiés à l'OS et 1.5, à la mémoire de stockage), et il n'est pas impossible (quoique très incertain) que les méthodes utilisées permettent d'écrire dans l'OS. Ce serait alors beaucoup moins risqué que les sycalls un peu barbares.
Remiweb a écrit : Donc en principe c'est faisable. Du coup à quoi correspondent les tests que tu avais fait pour écrire/lire ?
J'avais essayé d'aller écrire dans la mémoire logique avec un pointeur.
Matt36230 a écrit : On ne peut pas essayer de modifier sur l'émulateur ? C'est moins dangereux.
Pas vraiment non. L'émulateur n'est qu'un émulateur, on est à trop bas niveau pour qu'il permette de faire ça. Cela dit avec la mémoire de stockage, ça pourrait fonctionner.
Merci beaucoup pour les explications.
Pour une adresse donnée l'endroit où on va lire avec un pointeur n'est donc pas forcément le même que celui où on va écrire directement avec un syscall ?
Il faut bien comprendre que le pointeur ne représente qu'une donnée virtuelle. La mémoire logique n'est qu'une interface et le fait que l'OS s'y trouve à deux endroits différents le montre bien. Mais tout finit dans la mémoire physique, donc il y a bien un moment où la donnée que tu lis avec le pointeur est aussi celle qui est lue par le syscall. La différence, c'est que lorsqu'on passe par la mémoire logique, il faut montrer patte blanche au MMU, car c'est lui qui donne les droits d'accès -- et là par exemple il refuse les accès en écriture.
Cependant, les secteurs (dont il est sujet dans le syscall d'écrasement de syscall, évoqué par SimLo) relèvent purement de la mémoire physique, donc si tu dis au syscall « écrase-moi le secteur 2 » (par exemple), tu ne sais pas quelle est la zone de mémoire logique qui pointait dans le secteur 2 donc tu ne sais pas vraiment où tu écrases parce que quand tu programmes, quand tu documentes et quand tu penses, tu le fais en termes de mémoire logique.
Ouaip, c'est bien ça que j'avais en tête
Même en vérifiant avec un pointeur on n'est pas sûr de ce qu'on va écraser avec le syscall. Donc la vérification comme je l'avais proposé ne rend pas vraiment ça moins risqué...
Du coup existe-il un syscall pour lire ? Cette fois on serait sûr de lire et écrire au même endroit...
L'idée ce serait plutôt de désassembler les sycalls de Bfile pour voir si on peut récupérer des accès à la mémoire de stockage. Du coup on s'occuperait exclusivement de mémoire logique sans s'intéresser à l'agencement de la mémoire physique (i.e. les secteurs) et ça c'est beaucoup plus safe.
La première étape serait de se documenter sur Bfile. Si on a les infos pour écrire un tel add-in, je me ferai un plaisir de m'en charger
Ajouté le 19/08/2016 à 16:46 :
Je déterre un peu mais Gollum avait ramené le sujet sur le chat, et j'ai eu une idée sympa.
Techniquement on peut pas modifier l'OS avec un add-in (nada). TeamFX a fait sortir les sycalls qui réécrivent la Flash et c'est beaucoup trop risqués pour nous, qui ne pouvons pas corriger des erreurs en reprogrammant la ROM si on se trompe.
Ce qu'on peut faire c'est localiser la zone mémoire dans laquelle les glyphes se trouvent. Elle est, si je me souviens bien, indiquée quelque part dans la liste des syscalls. Ensuite on utilise le TLB pour rediriger cette adresse quelque part dans la RAM (est-ce possible ?).
Du coup, on n'a qu'à copier la zone mémoire (4 kio en général) dans la RAM et modifier les caractères dans la RAM -- aucun risque ici.
Cependant, jouer avec le TLB à l'insu du système est assez sensible. Ce n'est pas sans risque non plus, même si c'est sans doute plus tranquille que d'aller trifouiller la mémoire morte. Le mieux serait donc de lancer le programme Basic depuis l'add-in, et de restaurer le TLB à la sortie de l'add-in.
J'ai d'autres idées qui traînent, notamment une assez propre si on accepte de lancer le programme depuis l'add-in, mais faudrait développer.
Il n'y a pas de logiciel qui permette de faire ça automatiquement.
Du coup, il faut :
- Un OS compatible avec ta machine (disponibles dans la Bible)
- Un éditeur d'image (Gimp, Paint.NET, autre…)
- De quoi convertir les images en bytecode (le sprite coder par exemple)
- Un éditeur hexadécimal
- De quoi refaire le checksum de l'OS (cf Checksum Cleaner dans l'ancienne Bible)
En gros, tu refais les caractères que tu veux modifier. Tu les convertis en bytecode. Tu cherches dans l'OS le motif correspondant. Si y'en a plusieurs, t'essaie de trouver la bonne occurrence (ne pas modifier au hasard). Tu le remplace par le bytecode du nouveau caractère. Tu fais ça pour chaque caractère que tu veux modifier. Tu clean le checksum de l'OS pour que ça passe les tests de fxRemote. Tu balance sur ta calto.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Tu oublies qu'il faut quand même modifier l'OS, et c'est dangereux dans tous les cas.
Ajouter un mapping dans le MMU est peut-être plus safe mais à la réflexion, je ne pense pas que ce soit possible (voir « est-ce possible ? » dans mon message précédent). La raison en est simple, c'est P1 donc pas translaté par le MMU. Très peu de workarounds sont possibles.
On pourrait modifier quelques opcodes, certains sont faits pour ça, mais alors les programmes Basic ne seraient plus du tout compatibles avec les systèmes sans add-ins. (Et comme les systèmes monochromes avec add-ins ne sortent plus des usines de Casio...)
Oui, je sais, je suis un peu à la masse.
Avant de lire la question suivante, quelqu'un pourrait-il me dire si ce projet a eu des suites et des résultats ?
parce que j'ai beau chercher, je ne trouve nulle part l'os modifié contenants les caractères qu’apparemment, seul Remiweb a réussi à modifier...
Mais si ce projet vraiment super trop cool a malheureusement été abandonné, connaîtriez-vous la valeur hexadécimale d'un de ces caractères en basic casio ( la flèche vers le haut ▲ par exemple ...)
S'il vous plaît, répondez-moi !!!
Je ne crois pas qu'il y ait eu d'applications de cette technique. Pour ce qui est de la flèche, son code est e6 9c (sur deux octets). La liste complète des caractères est disponible dans les manuels du SDK. Une version en ligne se trouve dans la bible :
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 14/02/2016 12:00 | #
Je ne maîtrise pas du tout ça, désolé si je parle des mauvaises choses
(enfin je sais ce que sont les pointeurs et les syscall mais que en théorie...)
Ok. Un pointeur c'est une adresse dans la mémoire logique (de 0x00000000 à 0xffffffff). Les pointeurs couvrent donc 4 Gio de mémoire, dont on ne dispose bien évidemment pas. La mémoire physique ne fait que 4 Mio et de 256 kio à 512 kio de RAM selon les modèles. Une unité sur la puce, appelée le MMU (pour Memory Management Unit), est chargée de convertir les adresses logiques en entrées dans la mémoire physique pour accéder aux données.
L'OS se trouve à un endroit précis de la mémoire logique (0xa0000000, en fait il est aussi à 0x80000000, mais ce n'est pas une réelle copie : c'est le MMU qui redirige ces deux adresses vers la même zone de mémoire physique où l'OS réside), et on peut y lire, mais pas y écrire. Je peux donc parcourir l'OS en lecture si je veux.
Cependant, l'écriture est plus compliquée. On n'a pas les droits pour le faire avec des pointeurs (le MMU, encore une fois, nous empêche de le faire). Cependant, le système le fait : ne serait-ce que par le logiciel de mise à jour qui écrase toute la zone de mémoire dédiée à l'OS. Cela dit, l'écrasement de secteur ça se passe directement dans la mémoire physique donc on ne sait pas trop où on tape.
Mais maintenant que j'y pense, la gestion de la mémoire de stockage nécessite la modification d'une partie de la mémoire morte (les 4 Mio, donc 2.5 sont dédiés à l'OS et 1.5, à la mémoire de stockage), et il n'est pas impossible (quoique très incertain) que les méthodes utilisées permettent d'écrire dans l'OS. Ce serait alors beaucoup moins risqué que les sycalls un peu barbares.
Donc en principe c'est faisable. Du coup à quoi correspondent les tests que tu avais fait pour écrire/lire ?
J'avais essayé d'aller écrire dans la mémoire logique avec un pointeur.
On ne peut pas essayer de modifier sur l'émulateur ? C'est moins dangereux.
Pas vraiment non. L'émulateur n'est qu'un émulateur, on est à trop bas niveau pour qu'il permette de faire ça. Cela dit avec la mémoire de stockage, ça pourrait fonctionner.
Citer : Posté le 14/02/2016 12:53 | #
Merci beaucoup pour les explications.
Pour une adresse donnée l'endroit où on va lire avec un pointeur n'est donc pas forcément le même que celui où on va écrire directement avec un syscall ?
Citer : Posté le 14/02/2016 13:53 | #
Il faut bien comprendre que le pointeur ne représente qu'une donnée virtuelle. La mémoire logique n'est qu'une interface et le fait que l'OS s'y trouve à deux endroits différents le montre bien. Mais tout finit dans la mémoire physique, donc il y a bien un moment où la donnée que tu lis avec le pointeur est aussi celle qui est lue par le syscall. La différence, c'est que lorsqu'on passe par la mémoire logique, il faut montrer patte blanche au MMU, car c'est lui qui donne les droits d'accès -- et là par exemple il refuse les accès en écriture.
Cependant, les secteurs (dont il est sujet dans le syscall d'écrasement de syscall, évoqué par SimLo) relèvent purement de la mémoire physique, donc si tu dis au syscall « écrase-moi le secteur 2 » (par exemple), tu ne sais pas quelle est la zone de mémoire logique qui pointait dans le secteur 2 donc tu ne sais pas vraiment où tu écrases parce que quand tu programmes, quand tu documentes et quand tu penses, tu le fais en termes de mémoire logique.
Suis-je clair ?
Citer : Posté le 14/02/2016 14:27 | #
C'est toujours plus clair quand c'est toi qui explique, merci.
Citer : Posté le 14/02/2016 14:29 | #
Ouaip, c'est bien ça que j'avais en tête
Même en vérifiant avec un pointeur on n'est pas sûr de ce qu'on va écraser avec le syscall. Donc la vérification comme je l'avais proposé ne rend pas vraiment ça moins risqué...
Du coup existe-il un syscall pour lire ? Cette fois on serait sûr de lire et écrire au même endroit...
Citer : Posté le 14/02/2016 14:34 | #
L'idée ce serait plutôt de désassembler les sycalls de Bfile pour voir si on peut récupérer des accès à la mémoire de stockage. Du coup on s'occuperait exclusivement de mémoire logique sans s'intéresser à l'agencement de la mémoire physique (i.e. les secteurs) et ça c'est beaucoup plus safe.
La première étape serait de se documenter sur Bfile. Si on a les infos pour écrire un tel add-in, je me ferai un plaisir de m'en charger
Ajouté le 19/08/2016 à 16:46 :
Je déterre un peu mais Gollum avait ramené le sujet sur le chat, et j'ai eu une idée sympa.
Techniquement on peut pas modifier l'OS avec un add-in (nada). TeamFX a fait sortir les sycalls qui réécrivent la Flash et c'est beaucoup trop risqués pour nous, qui ne pouvons pas corriger des erreurs en reprogrammant la ROM si on se trompe.
Ce qu'on peut faire c'est localiser la zone mémoire dans laquelle les glyphes se trouvent. Elle est, si je me souviens bien, indiquée quelque part dans la liste des syscalls. Ensuite on utilise le TLB pour rediriger cette adresse quelque part dans la RAM (est-ce possible ?).
Du coup, on n'a qu'à copier la zone mémoire (4 kio en général) dans la RAM et modifier les caractères dans la RAM -- aucun risque ici.
Cependant, jouer avec le TLB à l'insu du système est assez sensible. Ce n'est pas sans risque non plus, même si c'est sans doute plus tranquille que d'aller trifouiller la mémoire morte. Le mieux serait donc de lancer le programme Basic depuis l'add-in, et de restaurer le TLB à la sortie de l'add-in.
J'ai d'autres idées qui traînent, notamment une assez propre si on accepte de lancer le programme depuis l'add-in, mais faudrait développer.
Citer : Posté le 02/10/2017 12:16 | #
eu mec c'est quel logiciel qui fait ça
Citer : Posté le 02/10/2017 13:10 | #
Il n'y a pas de logiciel qui permette de faire ça automatiquement.
Du coup, il faut :
- Un OS compatible avec ta machine (disponibles dans la Bible)
- Un éditeur d'image (Gimp, Paint.NET, autre…)
- De quoi convertir les images en bytecode (le sprite coder par exemple)
- Un éditeur hexadécimal
- De quoi refaire le checksum de l'OS (cf Checksum Cleaner dans l'ancienne Bible)
En gros, tu refais les caractères que tu veux modifier. Tu les convertis en bytecode. Tu cherches dans l'OS le motif correspondant. Si y'en a plusieurs, t'essaie de trouver la bonne occurrence (ne pas modifier au hasard). Tu le remplace par le bytecode du nouveau caractère. Tu fais ça pour chaque caractère que tu veux modifier. Tu clean le checksum de l'OS pour que ça passe les tests de fxRemote. Tu balance sur ta calto.
Citer : Posté le 03/10/2017 07:35 | #
M'enfin, via un addin qui lance les programmes basics, ce n'est pas possible ?
Citer : Posté le 03/10/2017 07:40 | #
Tu oublies qu'il faut quand même modifier l'OS, et c'est dangereux dans tous les cas.
Ajouter un mapping dans le MMU est peut-être plus safe mais à la réflexion, je ne pense pas que ce soit possible (voir « est-ce possible ? » dans mon message précédent). La raison en est simple, c'est P1 donc pas translaté par le MMU. Très peu de workarounds sont possibles.
On pourrait modifier quelques opcodes, certains sont faits pour ça, mais alors les programmes Basic ne seraient plus du tout compatibles avec les systèmes sans add-ins. (Et comme les systèmes monochromes avec add-ins ne sortent plus des usines de Casio...)
Citer : Posté le 03/10/2017 10:00 | #
Surtout que, s'il faut un addin pour lancer les programmes basic, autant coder le programme basic en addin
Ecrivez vos programmes basic sur PC avec BIDE
CARONantoine Invité
Citer : Posté le 23/04/2020 17:07 | #
Oui, je sais, je suis un peu à la masse.
Avant de lire la question suivante, quelqu'un pourrait-il me dire si ce projet a eu des suites et des résultats ?
parce que j'ai beau chercher, je ne trouve nulle part l'os modifié contenants les caractères qu’apparemment, seul Remiweb a réussi à modifier...
Mais si ce projet vraiment super trop cool a malheureusement été abandonné, connaîtriez-vous la valeur hexadécimale d'un de ces caractères en basic casio ( la flèche vers le haut ▲ par exemple ...)
S'il vous plaît, répondez-moi !!!
Citer : Posté le 23/04/2020 17:16 | #
Je ne crois pas qu'il y ait eu d'applications de cette technique. Pour ce qui est de la flèche, son code est e6 9c (sur deux octets). La liste complète des caractères est disponible dans les manuels du SDK. Une version en ligne se trouve dans la bible :
https://bible.planet-casio.com/common/casio/sdk_manuals/Character%20Set.pdf
CARONantoine Invité
Citer : Posté le 23/04/2020 17:57 | #
Super !
Merci merci merci !