Posté le 09/05/2018 17:27
sûrement les trucs GPIO, mais quoi d'autre ?
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 103 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 31/08/2018 11:06 | #
Il utilise la méthode C :
static int (*SysCall)( int R4, int R5, int R6, int R7, int FNo ) = (void*)&SysCallCode;
char* ML_vram_adress()
{
return (char*)((*SysCall)(0, 0, 0, 0, 309));
}
Je devrais la remplacer par la méthode assembleur ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/08/2018 11:10 | #
Pour autant que je me souvienne (ça fait un moment), il y avait deux méthodes C.
L'archive de Dark Storm dans le tuto de compatibilité SH4 du SDK propose cette version :
typedef char*(*sc_cpv)(void);
const unsigned int sc0135[] = { 0xD201D002, 0x422B0009, 0x80010070, 0x0135 };
#define ML_vram_adress (*(sc_cpv)sc0135)
Tu peux la tester ; ou alors tu peux te blinder en utilisant la version assembleur.
Mais bon, je ne suis pas sûr que le bug vienne de là, ML_vram_adress() a toujours marché sur les machines SH4 dans les add-ins que j'ai écrits personnellement... x)
Citer : Posté le 31/08/2018 11:17 | #
Ben, ça vient incontestablement de là : au début de mon addin j'ai mis un getkey suivi d'un ML_vram_adress() puis d'un autre getkey, si je vire le ML_vram_adress ou si je retourne au menu avant l'appel ça crashe pas, sinon ça crashe
Le code de DS ne compile pas (et je comprends rien aux pointeurs de fonctions
#define ML_vram_adress (*(sc_cpv)sc0135)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/08/2018 11:21 | #
Essaie ça, sinon passe à l'assembleur. Pas de casse-têtes inutiles.
const unsigned int sc0135[] = { 0xD201D002, 0x422B0009, 0x80010070, 0x0135 };
#define ML_vram_adress() (*((sc_cpv)&sc0135))()
Citer : Posté le 31/08/2018 11:22 | #
Toujours pas :
#define ML_vram_adress() (*((sc_cpv)&sc0135))()
Je vais essayer l'assembleur du coup.
Ajouté le 31/08/2018 à 11:44 :
Comment je fais pour que la procédure assembleur soit plus concise (enlever le truc putkey_code et mettre le numéro du syscall à la place) ?
mov.l syscall_table, r2
mov.l _putKey_code, r0
jmp @r2
nop
_putKey_code:
.long 0x910
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/08/2018 11:54 | #
Je ne sais pas trop pourquoi tu veux faire ça, mais... tu ne peux pas. Pour charger une valeur dans un registre, tu as deux choix :
1. mov #42, r0
La valeur à charger est écrite direct dans l'instruction. Mais comme les instructions font 2 octets, il n'y a la place que pour 1 octet de données. Conclusion : ce n'est possible que pour les valeurs entre -128 et 127.
Note qu'il n'y a pas de .b, .w ou .l : les 8 bits de données sont toujours étendus sur 32 bits (extension de signe) et toute la valeur du registre est écrasée.
2. mov.l @(12, pc), r0 et plus loin .long 0x42424242
Ici la valeur n'est pas écrite dans l'instruction mais elle est plus loin dans le programme, et l'instruction dit où : à 12 octets de PC (soit 12 octets plus loin que le mov.l, en gros). Ce mode est obligatoire pour toutes les valeurs qui ne tiennent pas sur 8 bits en signé, y compris 0x910.
Note qu'il y a ici un .b, .w ou .l pour indiquer combien d'octets sont à charger. Les autres octets de r0 ne sont pas changés ; par exemple dans un mov.b, seul l'octet de poids faible est modifié. Il faut souvent utiliser extu.b ou exts.b juste après.
On notera que c'est super chiant de calculer la distance entre le mov et l'endroit où est stockée la donnée, c'est pour ça que les gens ont inventés les labels. mov.l label, r0 suivi de label: .long 0x42424242 est un mécanisme fourni par le programme d'assemblage pour calculer automatiquement les distances. Ouf !
Pour conclure : tu n'as pas le choix, tu dois utiliser un mov différé.
En essayant d'écrire mov.l 0x910, r0, tu as reçu l'erreur pcrel too far. Comme tu n'as pas mis de # pour indiquer que 0x910 était la valeur que tu voulais charger (auquel cas il t'aurais dit que ça ne rentrait pas), il a interprété 0x910 comme l'adresse absolue de la valeur à charger. Il a ensuite calculé la distance avec PC, mais elle est énorme (PC vaut autour de 0x300000) donc elle ne tenait pas non plus dans le champ réservé de l'instruction mov.l (12 bits). D'où l'erreur "PC-relative address is too far (from PC)".
Citer : Posté le 31/08/2018 12:06 | #
C'est surtout pour que je change 2 trucs au lieu de 4 quand je veux mettre un nouveau syscall (pas renommer le nomsyscall_code)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/08/2018 12:13 | #
Dans ce cas, sous GCC, tu peux nomme le label 1 (n'importe quel chiffre de 1 à 9 ferait l'affaire) et ensuite tu t'y réfères sous le nom 1f (1 forward).
Ces labels existent pour permettre à l'utilisateur d'avoir des labels temporaires aux noms pas uniques. Dans ce cas, 3f représente le prochain 3 vers le bas et 7b le dernier 7 vers le haut.
Ajouté le 31/08/2018 à 12:14 :
Ça c'est si tes syscalls sont tous dans le même fichier, s'ils sont dans des fichiers différents ça n'a pas la moindre espèce d'importance, tu peux tous les appeler code si ça te chante...
Citer : Posté le 03/09/2018 13:27 | #
bonjour,
je ne sais pas si ce problème a déjà été rapporté mais sur ma 35+E tweakée, dans le shell, le retour en arrière (la touche DEL) ne supprime pas le dernier caractère mais rajoute un []. Après plusieurs test, j'ai réalisé qu'il mettait autant de [] que de caractères supprimables, et que si l'on retape un calcul derriere, ce dernier est bien interpreté, ce qui signifie que tout fonctionne et que ce n'est qu'un probleme d'affichage... Cordialement.
PS: j'ai un autre probleme: je ne sais pas comment faire une virgule ...la touche de la virgule au dessus de DEL a le meme effet que DEL...
Citer : Posté le 03/09/2018 13:30 | #
Pour le DEL qui ne marche pas (visuellement) dans le shell, c'est normal : le shell est une implémentation très basique, pas de scrollage ni même d'historique (pour ça que le backspace marche pas). On affiche à l'écran, on shifte la vram vers le haut pour scroller
Le problème de la virgule, je viens de le résoudre : je sais pas pourquoi mais j'avais assigné la virgule au retour arrière au lieu du caractère ',' x)
Merci de tes tests sinon
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 03/09/2018 15:44 | #
Je réfléchissais au problème concernant le peu de mémoire disponible que tu avais évoqué (je ne sais plus trop où, une RDP peut-être…), et je suis quand même curieux quant à la manière dont le GC arrive à déterminer les ressources qu'on lui octroie.
Ça vaudrait peut-être le coup aussi de se concentrer sur les machines SH4 (qui deviennent je pense sérieusement la norme, en particulier pour les générations qui auront à faire du Python en lycée) pour utiliser la mémoire supplémentaire qu'on peut y trouver.
Citer : Posté le 03/09/2018 15:46 | #
Je rappelle que la zone en question est 0x88040000:256k.
Citer : Posté le 04/09/2018 08:45 | #
Ma prof de maths nous a dit de se mettre au Python et j'aimerais savoir si le tiens est ok pour des programmes simples ?
Citer : Posté le 04/09/2018 11:23 | #
Evidemment (sinon il servirait un peu à rien
Par contre, il n'est pas disponible en mode examen.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 04/09/2018 12:32 | #
@Shadow15510
Pour du Python en mode examen, pas d'autre choix à ce jour que d'aller dans le milieu ou haut de gamme :
- Casio Graph 90+E, facilement trouvable actuellement dans les 65-100€
- NumWorks à 80€
- HP Prime, facilement trouvable actuellement dans les 115-195€
J'ai publié un classement hier soir avec toutes les informations, conseils et astuces :
https://tiplanet.org/forum/viewtopic.php?p=234890#p234890
Personnellement, si déjà tu serais partant pour la Graph 35+E, je te conseillerais la Graph 90+E. Il y a d'excellents prix en ligne actuellement, ça ne coûtera donc pas bien davantage pour un modèle nettement supérieur et parfois même moins cher que la NumWorks !
https://tiplanet.org/forum/viewtopic.php?f=23&t=21629
Citer : Posté le 04/09/2018 12:50 | #
Ok merci beaucoup
Citer : Posté le 08/09/2018 19:26 | #
Je viens de mettre en avant le projet, et la problématique du mode examen qui va avec :
https://tiplanet.org/forum/viewtopic.php?f=51&t=21825&p=235086#p235086
Citer : Posté le 09/09/2018 09:19 | #
Merci critor
(bon ça fait que faut que je bosse plus pour corriger les bugs
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 16/09/2018 10:52 | #
Bonjour Zezombye,
Félicitations pour ton travail! Je trouve que l'interface est bluffante.
Mais quand penses-tu que les float seront disponibles?
Bon courage et au plaisir de te lire,
Lolo
Citer : Posté le 13/11/2018 07:28 | #
J'en étais sûr que c'était une limite hardcodée è_é
On change ça en 4096, et hop on a 4032 octets de dispo
Une petite recherche binaire et la limite semble être dans les 5000 octets, du coup j'ai laissé 5000 pour l'instant.
Par contre, c'est dans la ram statique ça non ? Du coup j'ai tenté de faire :
mais ça me fait une erreur chelou :
const char* heap = malloc(5000);
^~~~~~
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 13/11/2018 10:38 | #
Par contre, c'est dans la ram statique ça non ? Du coup j'ai tenté de faire :
mais ça me fait une erreur chelou :
Tu as tout à fait raison, et la RAM statique fait 8 ko, donc c'est pas terrible. Pour ton problème, il te suffit d'écrire const char *heap; au début du fichier et ensuite heap = malloc(20000) tout au début de main(). S'il y a des constructeurs, fais-en un constructeur de plus haute priorité.