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 230 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 24/08/2018 03:19 | #
Ah, mais justement ça marche pas
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/08/2018 08:31 | #
Eh bien utilise ma version assembleur... mais juste l'appel à GetKeyWait(). Et lis le tuto de Ziqumu sinon tu ne vas rien comprendre...
Citer : Posté le 24/08/2018 08:59 | #
Oui mais il faut convertir l'assembleur en assembleur GCC, ce dont je n'ai aucune idée de comment faire
(et le tuto de ziqumu ne dit rien là dessus)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/08/2018 09:07 | #
Tiens, prends exemple là dessus : https://git.planet-casio.com/Dark-Storm/EasyInput/blob/master/EasyInput_.s
Dans le dossier t'as le même en .src pour le SDK
Citer : Posté le 24/08/2018 09:11 | #
C'est pas exactement les mêmes trucs :/ y'a juste le changement de .export en .global mais ça je savais déjà.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/08/2018 09:12 | #
Ce que je t'ai filé, c'est la procédure d'appel de syscall (avec ou sans arguments) pour GCC. Si ton truc marche pas, c'est que ça vient d'autre part je pense.
Citer : Posté le 24/08/2018 09:17 | #
J'ai toujours le même bug :/
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/08/2018 09:32 | #
Ce que je t'ai filé, c'est la procédure d'appel de syscall (avec ou sans arguments) pour GCC. Si ton truc marche pas, c'est que ça vient d'autre part je pense.
Il y a des arguments à mettre sur la pile.
J'ai toujours le même bug :/
Avec toujours le même code ? Un peu de sérieux, si tu as tenté quelque chose, essaie au moins de nous montrer quoi.
Citer : Posté le 24/08/2018 09:43 | #
J'ai juste adapté le code de DS :
.type _getkey, @function
_getkey:
mov.l sc_addr, r2
mov.l 5f, r0
jmp @r2
nop
5: .long 0x247
sc_addr: .long 0x80010070
Et j'utilise toujours le même code C qu'avant.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/08/2018 10:37 | #
Bon, j'ai pas testé, mais essaie ça... ça doit renvoyer une valeur en hexa, les 16 bits du haut sont la ligne, les 16 bits du bas la colonne.
_GetKeyWait_syscall:
sts.l pr, @-r15
; Make some space for the two first parameters
add #-4, r15
mov r15, r4
add #-4, r15
mov r15, r5
; Make some space for last parameter (address pushed to stack later)
add #-4, r15
mov r15, r1
; KEYWAIT_HALTON_TIMERON with a delay of zero (needed for menu to work)
mov #2, r6
mov #0, r7
; Push last parameter
mov.l r1, @-r15
; Allow return to menu
mov #0, r2
mov.l r2, @-r15
; Do the subroutine call
mov.l syscall_table, r1
mov.l getkeywait, r0
jsr @r1
nop
; Get return value
add #8, r15
mov.l @r15+, r1
mov.l @r15+, r0
shll16 r1
or r1, r0
; Restore stack and leave
add #20, r15
lds.l @r15+, pr
rts
nop
.align 4
syscall_table:
.long 0x80010070
getkeywait:
.long 0x0247
Citer : Posté le 24/08/2018 10:44 | #
Ca compile (mis à part les commentaires que j'ai dû enlever), mais cette fois ça me fait une system error "INTERRUPT" :
Juste avant, le SDK me fait une erreur "reserved instruction exception by code read access at 00334C40".
Je l'ai appelé comme le syscall normal : GetKeyWait_syscall(&column, &row, type_of_waiting, timeout_period, menu, &key); et comme une fonction qui ne prend pas d'argument : key = GetKeyWait_syscall(); mais ça me fait la même erreur :/
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/08/2018 11:32 | #
Ah oui, j'ai oublié de te dire, le prototype est int GetKeyWait_syscall(void), les paramètres sont fixés dans l'assembleur pour l'instant. Il faudra que je teste... ce soir peut-être, désolé, là je suis coincé par d'autres choses. >_<
Citer : Posté le 24/08/2018 20:27 | #
Voilà, en appuyant sur [EXIT] on peut faire aller le shell plus vite en mettant plus de boosters :
binwi, la shout est down, faut que je shitposte ailleurs
Ajouté le 24/08/2018 à 20:49 :
D'ailleurs, le truc system error interrupt n'apparaît (à ma connaissance) que lors d'un index d'array out of bounds, mais je vois pas comment le syscall pourrait causer ça...
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/08/2018 20:56 | #
Un index array out of bounds c'est indétectable en C, sauf si tu sors des mappings... mais ça c'est une TLB ERROR.
J'admets ne pas trop savoir exactement quelles sont les conditions pour une SysERROR INTERRUPT, mais dépasser d'un tableau me semble inadéquat. Par contre il peut y avoir un cas particulier où sortir du tableau déclenche d'autres choses fâcheuses, bien sûr.
Citer : Posté le 25/08/2018 08:36 | #
Perso, ça m'est arrivé quand j'essayais d'accéder à la 23ème case d'un array de 21 cases. C'est aussi consistant avec celle de memallox, qui s'est produite parce qu'il avait pas mis le \0 (et j'imagine qu'il dépassait aussi d'un buffer).
Je conjecturerais que ça se produit quand on essaie d'accéder à de la mémoire qui existe (donc pas de TLB error) mais qui n'est pas attribuée à l'addin.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 25/08/2018 09:13 | #
Bien tenté, mais ça c'est ADDRESS (R) et ADDRESS (W)...
Entre nous, l'OS de Casio n'est pas terrible, mais je suis quand même convaincu que la SysERROR INTERRUPT a quelque chose à voir avec une interruption.
J'en ai régulièrement dans gint, soit dit en passant, en général c'est quand je casse les timers, et ça persiste parfois au redémarrage. (Les registres concernés ne sont réinitialisés que sur un RESET.) Un simple buffer overflow ne pourrait pas faire ça.
Citer : Posté le 30/08/2018 18:44 | #
J'ai un bug chelou : j'ai réussi à tracer le crash sur SH4 à la fonction ML_pixel (j'ai pas testé les autres de la monochromelib). Ce qui est très bizarre, c'est que si on retourne au menu entre le lancement de l'addin et l'appel à ML_pixel, ça crashe pas, sinon ça crashe.
Une idée de pourquoi ce bug est causé (et seulement sur SH4), et pourquoi il est réglé par un appel au menu ?
En attendant je vais remplacer les fonctions de ML par leurs équivalents casio, mais j'aimerais quand même pouvoir utiliser ML.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 30/08/2018 18:52 | #
Affiche donc l'adresse de la VRAM utilisée par ML_pixel() pour voir ?
Citer : Posté le 30/08/2018 19:16 | #
ML_vram_adress() cause le crash, effectivement (même erreur). Par contre c'est bizarre : mon truc pour scroller le shell, qui appelle aussi ML_vram_adress(), marche parfaitement sans retour au menu.
Si je fais un retour au menu avant l'appel, l'adresse est 0x880085e9.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/08/2018 08:31 | #
Quelle est la méthode d'appel de syscall utilisée dans ta version de ML ? L'ancienne méthode n'était pas compatible SH4.
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