Syscalls : System ERROR
Posté le 26/12/2015 10:20
Hello,
avant de faire quoi que ce soit niveau jeux, j'essaye de comprendre la base, et c'est pour cela que je m'attaque à la première pierre des add-ins : les bibliothèques. En effet, plutôt que d'utiliser la libfx.a ou d'utiliser la MonochromeLib, j'essaye de faire ma propre version de la MonochromeLib tout en décortiquant son contenu et en adaptant la forme et l'utilisation.
J'ai donc été confronté au monde merveilleux des syscalls.
Au début, puisque je reprenais la MonochromeLib, j'ai repris sa partie syscall (pour la VRAM) et j'ai essayé d'isoler ce que j'ai pu dans une fonction auxiliaire pour en arriver à ce résultat :
caphics.h -
cph_syscall.c
Seulement, quand j'essaye de mettre ça sur ma calculatrice (avec un addin qui utilise cette bibliothèque, obviously), cela me fait une belle System ERROR avec :
TARGET=00000015
PC=00000001
J'ai essayé de remettre l'ancienne version du cph_syscall (celle avant que je ne tombe sur
ce topic), ça me fait un System ERROR aussi.
Du coup, je suis bloqué et je n'arrive pas à comprendre où je me suis foiré.
Le programme de test, c'est juste ça :
#include <caphics.h>
int main(void)
{
cph_setpixel(1, 1, black);
return (0);
}
Si vous pouvez me dire où je me suis trompé, ou même me donner des pistes/de la doc/n'importe quoi, ce serait super sympa de votre part
('pis cette librairie sera dispo publiquement, sous licence Creative Commons BY-SA, et je tenterai d'y mettre un maximum de choses, ainsi éventuellement qu'un tutoriel pour s'en servir si ça en intéresse certains)
Merci d'avance
Citer : Posté le 26/12/2015 11:33 | #
C'est pas dit que refaire une MLib (même adaptée) soit vraiment utile : 99% des addins l'utilisent et elle est pas trop mal optimisée. Enfin, si tu veux quand même faire concurrence, je ne peux pas t'en empêcher.
Concernant ton problème de syscall, c'est bien plus propre de les appeler en assembleur depuis un fichier source (.s sous Gnunux, .src sous Windows). Attention, selon ta plateforme de compilation, les fichiers assembleurs sont différents, le SDK de Casio ne respecte pas du tout les normes.
Du coup pour Gnunux le code donne ça
#define _SYSCALL_H
void getkey_wait(int* c, int* r, int type, int timeout, int menu, unsigned short* keycode);
int key_down(short key);
#endif // _SYSCALL_H
.global _getkey_wait // Nom du syscall
_getkey_wait:
mov.l sc_addr, r2
mov.l 1f, r0
jmp @r2
nop
1: .long 0x247 // Numéro du syscall
.global _key_down
_key_down:
mov.l sc_addr, r2
mov.l 1f, r0
jmp @r2
nop
1: .long 0x24B
sc_addr: .long 0x80010070
Attention, si tu veux faire une fonction de type "void execute_syscall(int syscall_id, ...)", c'est à dire avec arguments variables, faut faire gaffe parce que l'ordre des arguments est décalé de 1 à cause de syscall_id. Donc c'est un peu plus complexe à mettre en place.
Ajouté le 26/12/2015 à 11:35 :
Ah oui, au passage je te déconseille fortement de faire ça, parce que les syscalls peuvent être dangereux (faut pas exécuter le mauvais quoi x) ), donc on préfère les utiliser de manière constante.
Citer : Posté le 26/12/2015 11:42 | #
Tout d'abord, je ne veux pas faire concurrence, je souhaite surtout me servir d'outils que je comprends, et pour comprendre, refaire en analysant, c'est pas trop mal o/
Et oki, je vais tenter de faire ça en asm alors (c'est chaud, ça fait un moment qu'il faut que j'apprenne à coder en asm, mais je retarde l'inévitable). Le temps d'adapter mon Makefile et d'y include tout ça. Merci o_o
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 26/12/2015 11:45 | #
Disons que les Casio sont pas non plus hyper rapide, et que du coup pour certains projets l'ASM s'avère indispensable. Surtout au niveau des fonctions graphiques, puisque c'est elles qui prennent le plus de temps à s'exécuter.
Citer : Posté le 26/12/2015 11:58 | #
.global _getkey_wait // Nom du syscall
_getkey_wait:
mov.l sc_addr, r2
mov.l 1f, r0
jmp @r2
nop
1: .long 0x247 // Numéro du syscall
.global _key_down
_key_down:
mov.l sc_addr, r2
mov.l 1f, r0
jmp @r2
nop
1: .long 0x24B
sc_addr: .long 0x80010070
Quand je vois :
mov.l [blue]1[/blue]f, r0
...
[blue]1[/blue]: .long 0x247 // Numéro du syscall
puis pour la deuxième syscall :
mov.l [green]1[/green]f, r0
...
[green]1[/green]: .long 0x24B
on peut laisser le 1 avec 1f, il n'y aura pas de problèmes ?
Citer : Posté le 26/12/2015 12:06 | #
Ben le f permet de dire que c'est bien un long. Donc sans je doute que ça fonctionne.
Citer : Posté le 26/12/2015 12:07 | #
Ce que je veut dire c'est le chiffre devant le f avec le numéro du long ...
Citer : Posté le 26/12/2015 12:08 | #
Ah, oui
Enfin, chez moi ça fonctionne. Mais c'est sur que c'est mieux de mettre des noms différents.
C'est surtout parce que j'ai la flemme de tout changer lors des copier/coller
Citer : Posté le 26/12/2015 12:10 | #
Ok je demandais car j'avais vu sur EasyInput que tu mettais plusieurs numéros
Citer : Posté le 26/12/2015 12:17 | #
Du coup, comme ça, ça devrait être bon ? o_o (j'essaye simplement de récupérer l'adresse de la VRAM pour le moment, le reste viendra quand j'aurai déjà bien fait ce début)
caphics.h - cph_getvramaddress
(comme je sais pas trop comment le compiler, j'ai également utilisé gcc, mon Makefile me donne ça :
sh3eb-elf-gcc -Wall -Wextra -Werror -c -o obj/cph_setpixel.o -I includes src/cph_setpixel.c
...
je pense que ça marche o_o)
Mais du coup, ça me fait le même plantage que pour la version en C de tout à l'heure... o_o
Ajouté le 26/12/2015 à 12:35 :
Okay, donc non. Le programme ne ragequit plus, et tout marche parfaitement. Je sais pas encore exactement pourquoi (notamment pour le display qu'il me reste à comprendre), mais ça viendra. C'est beau. Merci beaucoup
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 26/12/2015 15:21 | #
on peut laisser le 1 avec 1f, il n'y aura pas de problèmes ?
Ben le f permet de dire que c'est bien un long. Donc sans je doute que ça fonctionne.
Non, le f veut dire forward ! C'est une fonctionnalité de gcc qui permet de définir des « labels locaux », et en l'occurrence 1f pointe sur le prochain symbole 1, alors que 1b pointe sur le précédent.
Rien à voir avec les long.
Citer : Posté le 26/12/2015 18:08 | #
Ah, au temps pour moi