Portage du malical sur calculatrice sh4 [Done]
Posté le 12/05/2018 13:48
Ce projet est d'ors et déjà terminé, n'hésitez pas à télécharger le résultat en pièce jointe
(les fonctions d'overclock n'ont pas été portés pour des raisons principalement d'ordre technique)
Je me suis lancé il y a peu dans la rédaction d'un tutoriel pour le langage de programmation nommé
Malical et développé il y a quelques années spécifiquement pour les calculatrices graphique monochrome de chez Casio.
À ma grande surprise, l'add-ins développé pour les sh3 s'est avéré marcher à merveille sur sh4, a un détail près, en effet les fonctions interagissant avec le RTC ne marche pas sur sh4 (d'après ce que j'ai compris des paroles de Lephé, l'adresse du syscall pour la RTC est différente sur sh4), et donc par extension, la seed pour l'aléatoire est toujours la même (donc c'est plus trop de l'aléatoire ^^ ), car cette seed (comme sur de nombreux programmes) est généré via des appels à la RTC.
Ainsi, me voyant mal faire un tuto sur un langage assez simple et idéal pour passer du Basic vers le C uniquement pour les propriétaires d'une calculatrice datant d'avant 2012, j'ai pour intention de porter le Malical pour les sh4.
J'ai donc téléchargé les
sources, puis commencé à analyser le code source. Après avoir compris la structure de fonctionnement du programme, j'ai été en mesure de localiser les endroits ou ça coince. Le principe de fonctionnement de ce langage est donc d’interpréter des fichiers texte avec un parser, puis appeler les fonctions en C correspondante avec les bons arguments, lorsque l'on trouve le nom d'une fonction (ya un passage par une sorte de dico qui associe les chaines de caractères censé appeler une fonction à la fonction en elles même,sans doute pour pouvoir utiliser les même noms de fonction que le SDK sans les appeler directement).
Les fonctions qui posent problème sont donc toutes celles qui interagissent avec le RTC:
void mcl_rtcreset (ObjectStack *,Object *);
void mcl_setyear (ObjectStack *,Object *);
void mcl_setmonth (ObjectStack *,Object *);
void mcl_setdomonth (ObjectStack *,Object *);
void mcl_setdoweek (ObjectStack *,Object *);
void mcl_sethour (ObjectStack *,Object *);
void mcl_setminute (ObjectStack *,Object *);
void mcl_setsecond (ObjectStack *,Object *);
void mcl_readyear (ObjectStack *,Object *);
void mcl_readmonth (ObjectStack *,Object *);
void mcl_readdomonth(ObjectStack *,Object *);
void mcl_readdoweek (ObjectStack *,Object *);
void mcl_readhour (ObjectStack *,Object *);
void mcl_readminute (ObjectStack *,Object *);
void mcl_readsecond (ObjectStack *,Object *);
void mcl_cpuspeed (ObjectStack *,Object *);
//Un exemple de à quoi ressemble les fonctions, attention, c'est condensé.
void mcl_setyear(ObjectStack *arg_stk,Object *objr)
{
int i;
if (arg_stk->size!=4) MalicalError(NUM_ERROR);
for (i=0;i<4;++i) if (!o_is_num(arg(i))) MalicalError(ARG_ERROR);
RTCSetYear ( value(0).d,value(1).d,
value(2).d,value(3).d);
obj_create(objr,VT_NIL,0);
}
Dans ces fonctions, ce qui pose problème, sont les fonctions CPUSpeed, RTCSet et RTCRead, toutes issues de la bibliothèque
Revolution-FX.
Je me suis donc ensuite lancé dans l'exploration des sources de Revolution-FX, et effectivement j'ai pu retrouver lesdites fonctions qui utilise belle et bien un syscall pour utiliser la RTC.Toutes ces fonctions sont écrite en C++ en utilisant la même 'structure': RTC
/*
Functions for accessing the RTC. The SuperH sees these values
as BCD (binary coded decimals).
Example:
thousands = 2;
hundreds = 0;
tens = 0;
ones = 7;
Will give you: 2007 in decimal
*/
struct st_rtc { /* struct RTC */
unsigned char R64CNT; /* R64CNT */
char wk1; /* */
union { /* RSECCNT */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char :1; /* */
unsigned char S10:3; /* 10sec */
unsigned char S1 :4; /* 1sec */
} BIT; /* */
} RSECCNT; /* */
char wk2; /* */
union { /* RMINCNT */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char :1; /* */
unsigned char M10:3; /* 10min */
unsigned char M1 :4; /* 1min */
} BIT; /* */
} RMINCNT; /* */
char wk3; /* */
union { /* RHRCNT */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char :2; /* */
unsigned char H10:2; /* 10sec */
unsigned char H1 :4; /* 1sec */
} BIT; /* */
} RHRCNT; /* */
char wk4; /* */
union { /* RWKCNT */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char :5; /* */
unsigned char WK:3; /* week */
} BIT; /* */
} RWKCNT; /* */
char wk5; /* */
union { /* RDAYCNT */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char :2; /* */
unsigned char D10:2; /* 10day */
unsigned char D1 :4; /* 1day */
} BIT; /* */
} RDAYCNT; /* */
char wk6; /* */
union { /* RMONCNT */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char :3; /* */
unsigned char M10:1; /* 10mon */
unsigned char M1 :4; /* 1mon */
} BIT; /* */
} RMONCNT; /* */
char wk7; /* */
union { /* RYRCNT */
unsigned short WORD; /* Word Access */
struct { /* Bit Access */
unsigned short Y1000:4; /* 1000year */
unsigned short Y100 :4; /* 100year */
unsigned short Y10 :4; /* 10year */
unsigned short Y1 :4; /* 1year */
} BIT; /* */
} RYRCNT; /* */
union { /* RSECAR */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char ENB:1; /* ENB */
unsigned char S10:3; /* 10sec */
unsigned char S1 :4; /* 1sec */
} BIT; /* */
} RSECAR; /* */
char wk8; /* */
union { /* RMINAR */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char ENB:1; /* ENB */
unsigned char M10:3; /* 10min */
unsigned char M1 :4; /* 1min */
} BIT; /* */
} RMINAR; /* */
char wk9; /* */
union { /* RHRAR */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char ENB:1; /* ENB */
unsigned char :1; /* */
unsigned char H10:2; /* 10sec */
unsigned char H1 :4; /* 1sec */
} BIT; /* */
} RHRAR; /* */
char wk10; /* */
union { /* RWKAR */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char ENB:1; /* ENB */
unsigned char :4; /* */
unsigned char WK :3; /* week */
} BIT; /* */
} RWKAR; /* */
char wk11; /* */
union { /* RDAYAR */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char ENB:1; /* ENB */
unsigned char :1; /* */
unsigned char D10:2; /* 10day */
unsigned char D1 :4; /* 1day */
} BIT; /* */
} RDAYAR; /* */
char wk12; /* */
union { /* RMONAR */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char ENB:1; /* ENB */
unsigned char :2; /* */
unsigned char M10:1; /* 10mon */
unsigned char M1 :4; /* 1mon */
} BIT; /* */
} RMONAR; /* */
char wk13; /* */
union { /* RCR1 */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char CF :1; /* CF */
unsigned char :2; /* */
unsigned char CIE:1; /* CIE */
unsigned char AIE:1; /* AIE */
unsigned char :2; /* */
unsigned char AF :1; /* AF */
} BIT; /* */
} RCR1; /* */
char wk14; /* */
union { /* RCR2 */
unsigned char BYTE; /* Byte Access */
struct { /* Bit Access */
unsigned char PEF :1; /* PEF */
unsigned char PES :3; /* PES */
unsigned char RTCEN:1; /* RTCEN */
unsigned char ADJ :1; /* ADJ */
unsigned char RESET:1; /* RESET */
unsigned char START:1; /* START */
} BIT; /* */
} RCR2; /* */
};
#define RTC (*(volatile struct st_rtc *)0xFFFFFEC0) /* RTC Address*/
//Et un petit exemple d'utilisation de cette structure:
void RTCSetYear(unsigned char thousands, unsigned char hundreds, unsigned char tens, unsigned char ones)
{
RTC.RYRCNT.BIT.Y1000 = thousands;
RTC.RYRCNT.BIT.Y100 = hundreds;
RTC.RYRCNT.BIT.Y10 = tens;
RTC.RYRCNT.BIT.Y1 = ones;
}
Cette énorme structure semble permettre d’accéder a chaque valeur du temps (années, mois, jour, ... ), stocké sous forme de BCD (j'avoue, sans les commentaires j'airais pas trouvé...).
maintenant, c'est là que j'ai besoin de votre aide, car si comprendre un code est une chose, le réécrire en est une autre... Et je ne sais pas par où commencer (corriger revolution-FX, réécrire l'add-ins...).
– Ai-je été clair, est-ce que je dois réexpliquer une partie?
– Est-ce que ma maigre compréhension du sujet est correct ? ou ai-je raté des trucs?
- Pour corriger le truc est-ce que remplacer l'adresse de la RTC sh3 par celle de la sh4 suffirait? (je me doute que non, ce serait trop simple, mais bon qui ne tente rien n'a rien
)
- Avez-vous réussi à lire jusqu'ici sans vous endormir ?
-A-t-on une librairie pour gérer le temps sur sh4? Sinon, comment utiliser le syscall de la RTC avec le sh4? (j'ai commencé à regarder comment c'était fais avec gint, mais les sources sont immenses et la partie que je recherche probablement en assembleur..)
Merci d'avoir pris le temps de me lire
Et merci d'avance pour la moindre piste que vous pourriez m'apporter.
Fichier joint
Citer : Posté le 12/05/2018 13:58 | #
Tu as tout juste et quasiment tout vu, bien joué !
Est-ce que c'est clair pour toi comment ces champs de bits permettent d'accéder à des parties précises des registres de la RTC ?
Et oui, tu as encore raison, il suffit de changer l'adresse de la RTC, parce que la structure est exactement la même ! Tout bénef'...
La partie RTC de gint est en fait pas en assembleur. Voilà comment ça se passe pour lire le temps...
https://git.planet-casio.com/lephe/gint/blob/master/src/rtc/rtc_getTime.c
Je te laisse chercher, si tu veux, les autres fichiers intéressants.
Concernant l'adresse de la RTC, il faut la chercher dans la doc du Renesas SH7724... ou dans les méandres de celle de SimLo. Je t'invite à faire les deux, il y a énormément de choses intéressantes à apprendre en les parcourant !
Citer : Posté le 12/05/2018 18:36 | #
Youpi
J'ai compris que l'on utilisait des plusieurs octets d’affilée pour lire individuellement chaque valeur (car un BCD tient sur un octet) que l'on désire, par contre, je vois moins à quoi servent les unsigned char vide au début de chaque sous structure, est-ce pour décaler la lecture? de même pour les char wk1, char wk2... ?
Nan, ya même pas un petit piège, j'étais persuadé que j'allais y passer des mois...
Effectivement, tu as exactement la même structure de déclarée dans /gint/include/modules/rtc.h (plus clairement tout de même), avec des pad(1) pour décaler je suppose. Puis tu cale un extern structure RTC pour récupérer l'adresse du RTC (je suppose car je n'ai pas trouvé, et si c'est le cas, ne me dis pas où elle est écris, j'ai envie d'aller trouver moi-même dans la doc)
Ok, c'est parti pour une autre expédition archéologique dans les tréfonds des docs Casio (j'aurais jamais pensé trouver fun de lire des docs et des codes sources à la recherche d'info
Citer : Posté le 12/05/2018 19:48 | #
En fait si tu vas voir dans la doc, tu as des choses comme ça...
64-Hz counter R64CNT R H'A465 FEC0 8
Second counter RSECCNT R/W H'A465 FEC2 8
Minute counter RMINCNT R/W H'A465 FEC4 8
Hour counter RHRCNT R/W H'A465 FEC6 8
Tous ces machins sont des registres, ie. des petites mémoires (de quelques octets) placés autour de la RTC. Il ne sont pas dans la RAM ni dans la Flash. Une technique pour y accéder (c'est la méthode « moderne ») est de leur faire correspondre une adresse mémoire, ou de les mapper. On parle alors de memory-mapped I/O.
Ici donc, le registre R64CNT (qui est utilisé par la fameuse fonction RTC_getTicks()) a pour adresse 0xa465fec0. Je te spoile un peu, c'est celui de la SH4. Mais tu le retrouveras tout seul !
La taille d'accès est de 8, ce qui veut dire que si on déréférence cette adresse avec un accès 1-octet (char, ou mieux uint8_t) on peut lire le contenu du registre. Je te préviens tout de suite, ça ne marche pas si on tente de lire l'adresse avec un int !
Maintenant en regardant un peu tout ça tu dois bien voir pourquoi il y a du padding dans ma structure. Les wk1 etc, ce sont des noms utilisés pour le padding par l'auteur de Revolution-FX. Personnellement je préfère un extern struct RTC et utiliser une variable globale que mettre une macro et recopier l'adresse partout dans le code. C'est un choix d'implémentation, pas un truc fondamental.
Je reviens rapidement sur les tailles d'accès et j'en profite pour te dire que tout pointeur vers des I/O mappées doit être marqué volatile, pour indiquer au compilateur que la valeur pointée peut changer dans son dos. Sinon il pourrait être tenté de faire des optimisations dessus !
int r64cnt = *ptr; /* OK */
volatile uint16_t *ptr = (void *)0xa465fec0;
int r64cnt = *ptr; /* Truc aléatoire, probablement 0 */
Citer : Posté le 12/05/2018 20:19 | #
Me revoilà, donc après avoir longtemps cherché dans la liste des fonctions, je me suis rendu compte qu'il s'agissait pas de fonction mais d'une adresse mémoire qui contient toutes les infos que l'on lit ou réécrit directement (est-ce vraiment une bonne idée d’écrire comme cela dans la mémoire? ), j'ai donc fini par trouver ce que je cherchais dans la doc de SimLo sur les différents registres selon les processeurs, ainsi pour les SH7291 et SH7337 (le dernier équipant la série des fx-9860G, soit les graph *5+USB ancienne version, il s’agit donc du fameux SH3) l'adresse du registre est belle et bien 0xFFFFFEC0, tandis que pour les SH7305 (Équipant les prizm, classpad et surtout les graph *5+USB nouvelle version, il s’agit donc du SH4) l'adresse est 0xA413FEC0, j'ai d’ailleurs trouvé un tableau qui résume les changements d'adresse de registre entre processeur (attention il pique les yeux) là
Il reste plus qu'à passer à la pratique
J’étais en train de rédiger ce message lorsque tu as posté le tient, donc tu ne m'as rien spoil du coup
Et merci encore pour ton aide
Citer : Posté le 12/05/2018 20:38 | #
Comme je l'ai précisé, ce n'est pas de la RAM. Ces adresses ont été spécialement assignées aux modules périphériques, donc tout va bien !
Bien joué sinon !
Citer : Posté le 12/05/2018 21:55 | #
Et voila les même info issue de la doc de Renesas, section 28 (ou page 941 à 970). Je pense que plus complet il n'y a pas (en vrai, je me mets surtout le lien pour moi
Citer : Posté le 12/05/2018 21:59 | #
Non, plus complet, il n'y a pas. Cette doc et toutes les associées sont la bible de TeamFX, que tu devrais certainement télécharger (si tu la retrouves). On y trouve aussi les docs de la RAM, de la Flash, de l'écran, des photos des cartes mères...
Souviens-toi par contre que les trois quarts des modules bizarres et non documentés du SH7724 (surtout le traitement graphique, audio et vidéo) n'existe bien sûr pas sur la calto.
Citer : Posté le 13/05/2018 12:03 | #
Après m'être battu avec le SDK, je suis fier d vous annoncer que le RTC marche enfin pour le Malical en version SH4, ainsi j'ai fait une découverte extraordinaire: L'heure est différente en fonction du moment de la journée
Cependant, cette grande nouvelle n'est que le début du chemin, il me reste encore à implémenter l'overclock (je sais pas si c'est safe, donc si c'est moi qui fais, on court probablement à la catastrophe
Je vais donc devoir revérifier une à une les différentes fonctions du Malical pour trouver s'il y a d'autres erreurs du genre.
Citer : Posté le 13/05/2018 12:15 | #
il me reste encore à implémenter l'overclock
Vu comment l'overclock de RFx était mauvais, je te déconseille d'improviser. Lis plutôt les sources de FTune2 pour te donner une idée propre de comment faire. Ce n'est peut-être pas le point le plus crucial de Malical...
Pour IsKeyDown(), jette un oeil du côté du patch SDK qui contient une alternative écrite en C et tout à fait propre pour SH4. C'est là-dessus que le SH4 CT se base.
Citer : Posté le 13/05/2018 12:26 | #
Oui, l'overclock est peut-être pas super important..
Donc je passe mon add-ins à la moulinette du SH4CT et c'est bon
(je rigole, je vais faire ça proprement, ce sera plus formateur
Ajouté le 13/05/2018 à 14:25 :
Donc, pour le patch du SDK, je mets le début du default.c au début de mon fichier. Et là j'ai plein de warning comme quoi il y a des redéfinitions de macros impossible,
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(55) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_LEFT" (declared at line 113 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(56) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_RIGHT" (declared at line 114 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(57) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_F1" (declared at line 115 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(58) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_F2" (declared at line 116 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(59) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_F3" (declared at line 117 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(60) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_F4" (declared at line 118 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(61) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_F5" (declared at line 119 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(62) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_F6" (declared at line 120 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(63) : C5047 (W) Incompatible redefinition of macro "KEY_CTRL_MENU" (declared at line 133 of "C:\Program Files\CASIO\fx-9860G SDK\OS\FX\include\keybios.h")
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(77) : C1016 (W) Argument mismatch
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(77) : C1016 (W) Argument mismatch
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(77) : C1016 (W) Argument mismatch
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(77) : C1016 (W) Argument mismatch
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(209) : C1016 (W) Argument mismatch
D:\Hackcell\Coding\CasioC\malical\src\Malical.c(210) : C1016 (W) Argument mismatch
et plus inquiétant, j'ai une erreur dans une lib standard
Citer : Posté le 13/05/2018 15:03 | #
Le truc c'est que le patch redéfinit les valeurs des numéros de touches parce que la nouvelle fonction IsKeyDown() les change de façon incompatible. Et là tu as cumulé les deux définitions : une est fournie par le patch, une par keybios.h qui est inclus par fxlib.h.
Regarde un peu keybios.h, en définissant la bonne macro au tout début de ton fichier tu peux l'empêcher de se faire inclure.
Il n'y a pas d'erreur dans la lib standard. Si l'erreur subsiste après que tu aies corrigé tes en-têtes, alors c'est qu'il y a un fichier qui a une erreur de syntaxe, et qui inclut string.h après l'erreur d'une façon subtile, de sorte que l'erreur n'est détectée qu'une fois dans string.h, même si elle ne vient pas de là.
Citer : Posté le 13/05/2018 17:39 | # |
Fichier joint
Peux-tu réexpliquer plus précisément ce que fait le code du patch? s'il te plait
Car j'ai du mal à comprendre pourquoi, il faut aller modifier keybios.h alors que normalement tout devrait marcher en mettent le code dans le default.c, et puis j'ai un problème avec certain morceau du patch, en effet les prototype des fonctions Iskeydown/up indique qu'elle renvoie des int, or on defini plus tard qu'elles sont en fait les fonctions keydown/up qui elles renvoient des unsigned char, il faut commenter d'autres morceau?
Enfin bref, je joins la version actuelle avec la clock corrigé
Citer : Posté le 13/05/2018 18:25 | #
Je n'ai pas été clair ; tu ne dois pas modifier keybios.h. Si tu y as touché, réinstalle-le !
La compatibilité entre les int et les unsigned char ne se posera pas comme un problème. C'est pas très joli en effet, mais tu peux laisser comme ça. Si tu tiens à modifier le code, mets des int partout.
Le patch implémente une autre fonction key_down() (je ne sais plus quel est le nom exact) qui utilise un truc spécifique SH4 pour lire le clavier. Mais cette fonction détecte les touches avec d'autres numéros. Le patch redéfinit donc KEY_CTRL_EXE et tous les autres noms de touches avec d'autres valeurs.
Le problème qui se pose c'est que tu risques d'avoir deux définitions pour KEY_CTRL_EXE, basiquement 30001 (donnée par keybios.h) et, si ma mémoire est bonne, 31 (donnée par le patch). C'est là que le compilo gueule.
Étant donné que keybios.h est utilisé par fxlib.h, tu ne peux pas empêcher son inclusion. Par contre si je me souviens bien il y a un header guard, donc en définissant la macro en question au début de chaque fichier tu peux empêcher ses contenus d'être interprétés, ce qui « cachera » les anciennes définitions.
Citer : Posté le 13/05/2018 23:11 | #
Bonne nouvelle, après passage au SH4CP, le programme marche à merveille, donc il doit belle et bien être possible de corriger le code via les sources, cependant, je pense que je c'est ma compréhension incomplète du patch qui fait que je rencontre des soucis pour placer au bon endroit le morceau de code. Ainsi, j'ai quelque question:
-Pourquoi inclure deux fois fxlib.h, une fois avant la déclaration du pragma __KEYBIOS_H__ et une fois après?
-Comment cela se fait que l'on utilise la fonction memcpy sans importer son prototype qui est dans string.h (et donc sa fonction dans string.obj)?
-Lorsque l'on déclare les nouveaux numéros de touches pour le IsKeydown, est-ce dans le but de remplacer uniquement ceux qui sont problématiques? ou autoriser uniquement l’utilisation de ces touches?
Voilà, actuellement ce qui me bloque..
Et encore une fois merci d'avance pour votre aide. (et un gros merci à Lephé pour toute son aide)
Citer : Posté le 14/05/2018 06:19 | #
- Tu ne l'inclus pas deux fois. Tu t'arranges juste pour que la macro (et non pragma) __KEYBIOS_H__ soit définie avant qu'il soit inclus, comme ça les définitions de keybios.h ne seront pas utilisées.
- Tous les compilateurs connaissent ce prototype par cœur, mais en toute rigueur il faut inclure string.h.
- Tous doivent changer parce que le nouveau key_down() utilise grosso modo les numéros du Basic. Au fond toutes les touches sont problématiques parce que c'est IsKeyDown() qui ne marche carrément pas. Et donc il faut vérifier que tout le code utiliser les macros (KEY_CTRL_EXE) et pas les nombres bruts (30001) sinon ça marchera pas...
Citer : Posté le 14/05/2018 22:34 | #
D'accord, donc en gros c'est un peu comme si je suprimais le contenu de keybios.h pour le remplacer par celui du patch? Dans ce cas si j'utilise d'autres macro définit dans keybios.h mais pas dans le patch, il faut que je les ajoute à la main dans le patch, c'est ça ?
Mon PC m'as lâché d'une manière assez inquiétante, donc je n'ai pas pus avancer beaucoup, mais j'ai compris l'erreur qui que j'obtenais avec string.h, cela venait du fait que je l'incluais après l'utilisation de memcpy...
Citer : Posté le 15/05/2018 07:46 | #
T'as tout compris !
Ok pour l'utilisation de memcpy() avant l'inclusion du proto, c'est une raison plus simple que ce que j'imaginais pour expliquer l'erreur
Citer : Posté le 17/05/2018 18:02 | # |
Fichier joint
J'ai finalement décidé de ne pas porter la fonction IskeyDown(), car getkey() et Waitkey() fonctionne à merveille. Cela serait redondant, de plus le patch modifie également le comportement de Getkey, qui est nécessaire au bon fonctionnement d'autres fonctions.
De plus, les fonctions d'overclock seront désactivés, car la réimplémentation bien qu’intéressante serait longue et leurs utilisations resteraient contreversé.
J'ai donc commenté le code concernant ces fonctions dans le cas où je change un jour d'avis (j’allai pas laisser le code en plan non plus
Donc merci beaucoup pour toute l'aide que tu m'as apporté, c'était fun et j'ai beaucoup appris.
(let me call you senpai from now on
Et puis je file préparer les tutos et la RDP
Citer : Posté le 17/05/2018 21:50 | #
Bien joué ! N'hésite pas à updater le post principal avec l'add-in en gros, poster sur la page originelle de Malical, et envoyer cet article à la RDP. C'est quand même pas rien d'avoir porté un langage !
Edit : You're welcome, kōhai!
Citer : Posté le 25/05/2018 21:11 | #
J'ai finalement décidé de ne pas porter la fonction IskeyDown(), car getkey() et Waitkey() fonctionne à merveille. Cela serait redondant
En fait c'est faux, Iskeydown est le seul moyen de vérifier les touches enfoncé sans mettre en pause le programme, contrairement aux Waitkey (ça c'est évident), et au Getkey. Au final, celui qui est redondant serait plutôt Waitkey.
Ajouté le 25/05/2018 à 21:12 :
Donc je m'y remets ce weekend...
Ajouté le 26/05/2018 à 11:13 :
Donc j'ai déjà trouvé comment je vais m'y prendre, en effet je vais créer une fonction Iskeydown custom qui reprend celle du patch proposé par DS et rajouter un switch pour faire correspondre les anciennes code de touche avec les nouveaux.
Cependant je me posais la question sur la vitesse d'un telle switch, qui contiendrait donc 50 case, en langage interprété, nul doute que le code s'en trouverait ralentit, qu'en est-t-il en C? mais peur sont-elles fondées