Posté le 26/08/2021 16:31
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 99 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 26/08/2021 16:34 | #
Sinon utilise Gint, c'est de loin la solution la plus puissante et la plus simple.
Le SDK de Casio (avec MonochromeLib) c'était déjà un enfer pour la Graph 75+E, fallait passer le g1a dans un outil pour avoir un fichier compatible SH4, ou pire : se taper un code de compatibilité à la main, du genre énorme et sale. Alors la Graph 35+E II, bon courage
Citer : Posté le 26/08/2021 16:35 | #
il faut trouver une suite d'octet et de le modifier
Citer : Posté le 26/08/2021 16:37 | #
N'oublie pas qu'il y a ce topic pour ça avec la description des changements. Remplacer une série d'octets ne suffit pas parce que le code est compilé à chaque fois, donc la séquence peut varier (en particulier à cause de l'allocation de registres). Chaque add-in utilise aussi MonochromeLib de façon différente parce que MonochromeLib n'active que les fonctions que l'on demande. Il faut donc chercher indépendamment ML_clear_screen, ML_display_vram, et les fonctions de contraste (qu'on ne sait pas transformer d'ailleurs il me semble).
Des stats sur les variations dans l'allocation de registre seraient utiles. Si le compilo du SDK est assez consistant, ça peut se finir en rechercher/remplacer. Mais c'est pas garanti en tous cas
Citer : Posté le 26/08/2021 17:09 | #
oh ok, tu n'aurais pas par hasard la suite d'octets a changer s'il te plait.
Citer : Posté le 26/08/2021 18:25 | #
Comme je viens de l'expliquer, c'est plus compliqué. En plus du fait que le compilateur peut changer les registres ou l'ordre des instructions (et il vaut mieux supposer qu'il le fait tant qu'on n'a pas une série de G1A pour suggérer le contraire), la séquence est super courte donc elle peut apparaître ailleurs hors du code MonochromeLib, et trouver des preuves indiscutables (les références à l'adresse de l'interface de l'écran) nécessite un désassembleur.
Cela étant dit, même avec Redcmd on n'a pas vraiment passé de temps à automatiser la modification du binaire, donc tout ce que je raconte là n'est pas trop difficile une fois qu'on sait ce qu'on veut.
Il se peut qu'un rechercher/remplacer soit suffisant pour avoir un résultat qui marche pas trop mal... et qui fasse crasher l'add-in un peu exceptionnel que t'as pas vu venir. À toi de voir si ça te suffit ou si tu veux un outil fiable comme le SH4 Compatibility Tool.
Je serai ravi d'expliquer les subtilités ; mais si elles ne t'intéressent pas alors prends au moins le temps de rechercher le sujet du remplacement. Quand tu partages un outil bas-niveau comme ça les gens te font confiance pour savoir ce que tu fais. Ici tu ne risques que des crash donc rien de pire que le lancement d'un add-in incompatible, mais quand même.
Au passage si tu cherches un peu tu sauras aussi qu'il y a des checksums dans un G1A, si tu ne les recalcules pas ton add-in modifié ne se lancera pas.
Citer : Posté le 26/08/2021 19:01 | #
c'est en cours mais j'ai un problème:
dans le programme j'ouvre le .g1a en tant que fichier binaire
dans la code je le charge en une liste d'octets (unsigned char)
et je cherche dans chaque octets 0xeb (c'est encore des tests)
dans mon éditeur hexadécimal je trouve la séquence a modifier
mais mon programme ne le trouve pas!
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv){
if(argc == 1){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no input and output file!\n");
return -1;
}
if(argc == 2){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no output file!\n");
return -1;
}
if(access(argv[1], F_OK ) == 0) {
//none
} else {
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("cannot open file!\n");
return -1;
}
printf("\033[0;37m"); //white text
FILE * file; //file pointer
file = fopen(argv[1], "rb"); //open file
fseek(file, 0L, SEEK_END); //seek file size
int filesize = ftell(file); //get file size
unsigned char filedata[filesize]; //make file data table
for(int i=0; i<filesize; i++){
filedata[i] = 0x00;
}
fread(filedata, sizeof(filedata), 1, file); //set file data in filedata table
fclose(file); //close input file
int addr = 0; //address of data to change
printf("filesize: %d\n",filesize);
for(int i=0; i<filesize; i++){
if(filedata[i] == 0xeb){
printf("find!\n");
}
}
//file = fopen(argv[2], "wb"); //open output file
//write final data in output file
//fwrite(filedata , sizeof(char) , filesize , file);
//fclose(file); //close output file
return 1;
}
Citer : Posté le 26/08/2021 19:06 | #
Indice : regarde la valeur de retour de fread(). (Le problème est lié au fseek().)
Tu devrais certainement allouer filedata avec malloc, la pile n'est pas énorme.
Citer : Posté le 26/08/2021 19:12 | #
je vous pas le problème avec fseek
je fais
et ça me retourne la bonne taille du ficher
et je vais allouer avec malloc
Ajouté le 26/08/2021 à 19:19 :
j'ai finit! mais ça ne change rien
ça donne
fread result: 0
filesize: 155304
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv){
if(argc == 1){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no input and output file!\n");
return -1;
}
if(argc == 2){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no output file!\n");
return -1;
}
if(access(argv[1], F_OK ) == 0) {
//none
} else {
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("cannot open file!\n");
return -1;
}
printf("\033[0;37m"); //white text
FILE * file; //file pointer
file = fopen(argv[1], "rb"); //open file
fseek(file, 0L, SEEK_END); //seek file size
int filesize = ftell(file); //get file size
unsigned char* filedata = NULL; //make file data table
filedata = malloc(filesize);
for(int i=0; i<filesize; i++){
filedata[i] = 0x00;
}
int fread_result = fread(filedata, sizeof(filedata), 1, file); //set file data in filedata table
printf("fread result: %d\n",fread_result);
fclose(file); //close input file
int addr = 0; //address of data to change
printf("filesize: %d\n",filesize);
for(int i=0; i<filesize; i++){
if(filedata[i] == 0xeb){
printf("find!\n");
}
}
//file = fopen(argv[2], "wb"); //open output file
//write final data in output file
//fwrite(filedata , sizeof(char) , filesize , file);
//fclose(file); //close output file
free(filedata);
return 1;
}
Citer : Posté le 26/08/2021 20:06 | #
Rappelle-toi du manuel de fread :
On success, fread() and fwrite() return the number of items read or written.
La raison pour laquelle tu n'as rien lu est parce que tu es à la fin du fichier.
Citer : Posté le 26/08/2021 20:44 | #
ça marche!
merci beaucoup!
plus qu'a modifier les octets comme il le faut
Ajouté le 26/08/2021 à 21:12 :
j'arrive a des résultats mi-concluants:
je peux voir les sprites sur ma G35+EII mais l'affichage est très beuggé il y a des lignes blanches qui défile comme sur une vhs et pleins de bugs graphique, mais j'arrive a explorer les menus (même avec 40% de l’écran qui bug)
j'ai du me tromper quelque-part!
je me base sur cette image:
Citer : Posté le 26/08/2021 21:17 | # |
Fichier joint
voila le fichier du résultat
Citer : Posté le 26/08/2021 21:17 | #
On a les sources de Mipjabok, qu'est-ce que tu essaies de faire ? Cette méthode c'est pour les programmes dont on n'a pas les sources !! o_o
Citer : Posté le 26/08/2021 21:19 | #
c'est pour les programmes ou on a pas la source, Mipjabok c'est juste un add-in de test
Citer : Posté le 26/08/2021 21:21 | #
Commence par essayer sur Gravity Duck alors, pour voir si tu as la même chose que GravdG35.g1a.
Citer : Posté le 26/08/2021 21:25 | #
ca marche très bien sur gravity duck
Ajouté le 26/08/2021 à 21:27 :
gravity duck est codé en c et Mipjabok en c++
le code doit changer avec les optimisations
Citer : Posté le 26/08/2021 21:28 | #
Ça c'est très probable oui, c'est carrément pas le même compilateur (c'est pas faute de l'avoir suggéré
Citer : Posté le 26/08/2021 21:29 | #
je vais essayer un autre jeu codé en c avec le sdk
Ajouté le 26/08/2021 à 21:33 :
ca ne fonctionne pas sur gravityGuy
Citer : Posté le 27/08/2021 00:13 | #
One of the main differences between the GraphE35 + II and older calculators is the pyhiscal display was changed
The new display requires different codes to operate making it incompatible
Heres a link to a page of compatible programs la-compatibilite-des-add-in-sur-la-graph-35e-ii
Here is the code from MonochromeLib which writes the vram to the display
{
char *LCD_register_selector = (char *)0xB4000000, *LCD_data_register = (char *)0xB4010000, *vram;
int i, j;
vram = ML_vram_address();
for (i = 0; i < 64; i++)
{
*LCD_register_selector = 4;
*LCD_data_register = i | 192;
*LCD_register_selector = 4;
*LCD_data_register = 0;
*LCD_register_selector = 7;
for (j = 0; j < 16; j++)
*LCD_data_register = *vram++;
}
}
The addresses 0xB4000000 and 0xB4010000 is where the display is connected to the circuit board and is used to control it
and here is the updated code to work with the GraphE35 + II
void ML_display_vram()
{
char *LCD_register_selector = (char *)0xB4000000, *LCD_data_register = (char *)0xB4010000, *vram;
int i, j;
vram = ML_vram_address();
for (i = 0; i < 64; i++)
{
*LCD_register_selector = 8;
*LCD_data_register = i | 128;
*LCD_register_selector = 8;
*LCD_data_register = 4;
*LCD_register_selector = 10;
for (j = 0; j < 16; j++)
*LCD_data_register = *vram++;
}
}
notice how the codes 4, 192, 0 and 7 have been changed
this is because those codes were changed between the old and new displays
you can read up on what the codes are in T6K11 Display Manual
the code 4 corresponds to the operation Set Y−address (which is on page 25/47)
and i is the row to draw the current pixel to (with a off set of 192)
To make the MonochromeLib display_vram function compatible with all versions
You can simpliy test to see what calc it is and change the codes accordingly
{
(char*)((*SysCall)(OS, 0, 0, 0, 0x2EE));
}
void ML_display_vram()
{
volatile char *LCD_register_selector = (char *)0xB4000000;
volatile char *LCD_data_register = (char *)0xB4010000;
char Data_Buffer = 7, XY_Register = 4;
char row = 0xC0, col = 0;
char OS[10];
int i, j;
char *vram = ML_vram_address();
System_GetOSVersion(OS);
if (OS[1] == '3')
{
Data_Buffer = 10;
XY_Register = 8;
row = 0x80;
col = 4;
}
for (i = 0; i < ML_SCREEN_HEIGHT; i++)
{
*LCD_register_selector = XY_Register; // 4 => 8
*LCD_data_register = row; // 0xC0 => 0x80
*LCD_register_selector = XY_Register; // 4 => 8
*LCD_data_register = col; // 0 => 4
*LCD_register_selector = Data_Buffer; // 7 => 10
for (j = 0; j < ML_SCREEN_WIDTH / sizeof(char); j++)
*LCD_data_register = *vram++;
row++;
}
}
Heres a code breakdown view that the sdk gives us (in the debug folder)
00000034 _ML_display_vram: ; function: ML_display_vram
; frame size=20
00000034 2FC6 MOV.L R12,@-R15
00000036 2FB6 MOV.L R11,@-R15
00000038 2FA6 MOV.L R10,@-R15
0000003A 2F96 MOV.L R9,@-R15
0000003C 4F22 STS.L PR,@-R15
Monochrome 40 {
Monochrome 41 char *LCD_register_selector = (char *)0xB4000000, *LCD_data_register = (char *)0xB4010000, *vram;
Monochrome 42 int i, j;
Monochrome 43 vram = ML_vram_address();
0000003E D32C MOV.L L719+6,R3 ; _VRam_Base
00000040 430B JSR @R3
00000042 0009 NOP
Monochrome 44 for (i = 0; i < 64; i++)
00000044 D52B MOV.L L719+10,R5 ; H'B4000000
00000046 6C03 MOV R0,R12
00000048 D42B MOV.L L719+14,R4 ; H'B4010000
0000004A E940 MOV #64,R9
0000004C EA10 MOV #16,R10
0000004E EB07 MOV #7,R11
00000050 E100 MOV #0,R1
00000052 E704 MOV #4,R7
00000054 6013 MOV R1,R0
00000056 L649:
Monochrome 45 {
Monochrome 46 *LCD_register_selector = 4;
Monochrome 47 *LCD_data_register = i | 192;
00000056 E2C0 MOV #-64,R2
00000058 2570 MOV.B R7,@R5
Monochrome 48 *LCD_register_selector = 4;
Monochrome 49 *LCD_data_register = 0;
Monochrome 50 *LCD_register_selector = 7;
Monochrome 51 for (j = 0; j < 16; j++)
0000005A 66A3 MOV R10,R6
0000005C 220B OR R0,R2
0000005E 2420 MOV.B R2,@R4
00000060 2570 MOV.B R7,@R5
00000062 2410 MOV.B R1,@R4
00000064 25B0 MOV.B R11,@R5
00000066 L650:
00000066 4610 DT R6
Monochrome 52 *LCD_data_register = *vram++;
00000068 63C4 MOV.B @R12+,R3
0000006A 8FFC BF/S L650
0000006C 2430 MOV.B R3,@R4
0000006E 7001 ADD #1,R0
00000070 3093 CMP/GE R9,R0
00000072 8BF0 BF L649
Monochrome 53 }
Monochrome 54 }
00000074 4F26 LDS.L @R15+,PR
00000076 69F6 MOV.L @R15+,R9
00000078 6AF6 MOV.L @R15+,R10
0000007A 6BF6 MOV.L @R15+,R11
0000007C 000B RTS
0000007E 6CF6 MOV.L @R15+,R12
and as you can see it matches up perfectly with the disassembled asm code
002c1e 2fb6 mov.l r11, @-r15
002c20 2fa6 mov.l r10, @-r15
002c22 2f96 mov.l r9, @-r15
002c24 4f22 sts.l pr, @-r15
002c26 d32c mov.l @(h'b0,pc), r3 ;@(h'2cd8)
002c28 430b jsr @r3
002c2a 0009 nop
002c2c d52b mov.l @(h'ac,pc), r5 ;@(h'2cdc)
002c2e 6c03 mov r0, r12
002c30 d42b mov.l @(h'ac,pc), r4 ;@(h'2ce0)
002c32 e940 mov #h'40, r9
002c34 ea10 mov #h'10, r10
002c36 eb07 mov #h'7, r11
002c38 e100 mov #h'0, r1
002c3a e704 mov #h'4, r7
002c3c 6013 mov r1, r0
002c3e e2c0 mov #h'ffffffc0, r2
002c40 2570 mov.b r7, @r5
002c42 66a3 mov r10, r6
002c44 220b or r0, r2
002c46 2420 mov.b r2, @r4
002c48 2570 mov.b r7, @r5
002c4a 2410 mov.b r1, @r4
002c4c 25b0 mov.b r11, @r5
002c4e 4610 dt r6
002c50 63c4 mov.b @r12+, r3
002c52 8ffc bf/s h'-8 ;@(h'2c4e)
002c54 2430 mov.b r3, @r4
002c56 7001 add #h'1, r0
002c58 3093 cmp/ge r9, r0
002c5a 8bf0 bf h'-20 ;@(h'2c3e)
002c5c 4f26 lds.l @r15+, pr
002c5e 69f6 mov.l @r15+, r9
002c60 6af6 mov.l @r15+, r10
002c62 6bf6 mov.l @r15+, r11
002c64 000b rts
002c66 6cf6 mov.l @r15+, r12
if we don't have the source code to a project, we can just modify the code at line 002c36 to 002c3c using a hexidecimal editor
Citer : Posté le 27/08/2021 10:25 | #
oh, thank you so much
Ajouté le 27/08/2021 à 11:58 :
quand je compare gravity duck version originale et version G35
ça ne correspond pas...
0000076D 07 0A
0000076F 00 04
00000771 04 08
00000772 60 E0
00000773 13 00
00000777 C0 80
Citer : Posté le 27/08/2021 12:16 | #
(Je réalise que j'ai un été un peu sec hier, je m'en excuse.)
Tu peux voir quelques variations déjà en regardant les extraits de Redcmd. Regarde cette section :
0000004E EB07 MOV #7,R11
00000050 E100 MOV #0,R1
00000052 E704 MOV #4,R7
00000054 6013 MOV R1,R0
00000056 L649:
Monochrome 45 {
Monochrome 46 *LCD_register_selector = 4;
Monochrome 47 *LCD_data_register = i | 192;
00000056 E2C0 MOV #-64,R2
00000058 2570 MOV.B R7,@R5
Note que le (mov r1, r0) de code 0x6013 est suivi immédiatement du (mov #-64, r2) de code 0xe2c0 et ensuite seulement du (mov.b r7, @r5) de code 0x2570.
Tandis que dans Gravity Duck:
L'ordre est inversé, le (mov.b r7, @r5) précède le (mov #-64, r2). Les deux versions du code sont correctes ; je crois que celle de Gravity Duck gagne un cycle sur SH3. Dans tous les cas, c'est à ce genre de différences que je faisais allusion.
(Je ne saurais pas quoi ajouter à ton post ci-dssus parce que je ne vois pas quel octets tu références.)