La Place des Développeurs FUSION-C Codez en C pour MSX les doigts dans le nez !
ericb59
Membre non connecté
Conseiller Municipal
Reprise du message précédent
@aoinekoMerci pour ces remarques que je vais prendre en compte. Même si sans doute je ne vais pas toutes les appliquer, ca me fait progresser.
Il y a certaines de tes remarques que je ne comprend pas, je te demanderai plus d'explications ultérieurement.
Pour "justifier" un peut ce joyeux "bordel" et mon manque de respect des conventions, c'est que je ne suis pas un pro dans le domaine, je fais tout un peu à ma "sauce"
A l'origine ce projet de librairie était destiné à mon seul usage, puis je me suis dit que c'était un peu bête de ne pas partager mon travail avec la communauté, car très certainement d'autres personnes pourraient en avoir usage. Donc, j'ai poussé un peu plus les choses pour faire quelque chose de sympathique à utiliser sans trop se prendre la tête sur les moyens de programmer en C pour MSX, et surtout quelques chose d'automatisé.
Bref, je ne suis pas contre le fait de standardiser tout ça Et ton aide est précieuse, vu que dans une seule t^te il y a moins d'idées que dans plusieurs
Je reviens plus tard avec des modifs et des question ...
Edité par ericb59 Le 16/11/2020 à 11h32
ericb59
Membre non connecté
Conseiller Municipal
Citation :
- Je ne sais pas pourquoi tu as pas mis le "e" de "compile" mais de toute façon, vu le contenu du script (compile + link + deploy) il devrait plutôt s’appeler "build". Ceci dit, ça serait bien d’avoir aussi un script qui ne fait que la partie compilation car c’est très pratique de pouvoir compiler les fichiers C indépendamment depuis l’IDE.
J'ai modifié le noms des scripts pour build.sh et build.bat
J'ai conçu ces scripts (usine à gaz ) pour qu'ils puissent être appelés de façon autonome depuis le Shell / Dos en dehors de tout Ide.
Il y a pour cela une manip particulière à faire pour que ca fonctionne. Voir la doc Chapitre FAQ.
Mais je vais plutôt ré-intégrer ça dans le chapitre Installation, comme étant une fonctionnalité de base pour plus de clarté.
Citation :
- Ensuite, je déconseille fortement de demander à l’utilisateur de copier hex2bin.exe dans le dossier de System32 de Windows. C’est une façon de faire qui n’est plus "legit". Chez moi j’ai corrigé le script pour qu’il aille chercher directement hex2bin dans le répertoire \Tools\.
Suite à ta remarque j'ai changé son emplacement où placer l'exécutable (voir le nouveau manuel), on le mets dorénavant au même endroit que s'install SDCC.exe
J'aurais pu faire en sorte de garder cet executable dans Tools, comme tu le propose. Mais ca m'ennuyais car je souhaitais que cet outils soit appelle directement depuis le DOS, pour que le script build.bat puisse s'exécuter par un call manuel.
Citation :
- Il faudrait garder les fichiers intermédiaires (à mettre dans un répertoire \out\ ou \intermediate\).
C'est fait. Un dossier OUT se crée automatiquement et les fichiers temporaires y sont copiés à chaque compilation.
C'est update sur Github.
pour le reste de tes remarques, j'ai des question ... J'y reviendrai ...
Edité par ericb59 Le 16/11/2020 à 11h31
aoineko
Membre non connecté
Conseiller Municipal
T'inquiète pas, moi aussi j'ai plein d'usines à gaz un peu partout. Le tout c'est de les encapsuler proprement pour pas faire peur aux utilisateurs (même quand c'est pour soi-même).
Au boulot, j'ai un collègue qui m'appelle batman ; parce(j'ai tendance à faire des outils de build en .bat assez « conséquent ».
Si ton répertoire Tools\ fait parti du package, tu peux y accéder sans soucis depuis ton répertoire de build. C'est exactement ce que je fais dans ma lib. Dans le chemin de fichier, tu peux utiliser ..\ pour revenir un cran en arrière dans l'arborescence des répertoires. Ma modification de l'ex Compil.bat, c'était juste de mettre set HEX2BIN="%CURRENT_DIR%..\Tools\Hex2Bin\Hex2bin Windows\hex2bin.exe".
Au boulot, j'ai un collègue qui m'appelle batman ; parce(j'ai tendance à faire des outils de build en .bat assez « conséquent ».
ericb59 :
Suite à ta remarque j'ai changé son emplacement où placer l'exécutable (voir le nouveau manuel), on le mets dorénavant au même endroit que s'install SDCC.exe
J'aurais pu faire en sorte de garder cet executable dans Tools, comme tu le propose. Mais ca m'ennuyais car je souhaitais que cet outils soit appelle directement depuis le DOS, pour que le script build.bat puisse s'exécuter par un call manuel.
J'aurais pu faire en sorte de garder cet executable dans Tools, comme tu le propose. Mais ca m'ennuyais car je souhaitais que cet outils soit appelle directement depuis le DOS, pour que le script build.bat puisse s'exécuter par un call manuel.
Si ton répertoire Tools\ fait parti du package, tu peux y accéder sans soucis depuis ton répertoire de build. C'est exactement ce que je fais dans ma lib. Dans le chemin de fichier, tu peux utiliser ..\ pour revenir un cran en arrière dans l'arborescence des répertoires. Ma modification de l'ex Compil.bat, c'était juste de mettre set HEX2BIN="%CURRENT_DIR%..\Tools\Hex2Bin\Hex2bin Windows\hex2bin.exe".
On est toujours ignorant avant de savoir.
ericb59
Membre non connecté
Conseiller Municipal
@Franck : En fait il y a assez peut de fonctions qui changent, par contre il y en a plus.
C'est surtout autour de la façon d'utiliser que j'ai fait pas mal de changements.
donc, oui attends la 1.3 ça sera plus clair.
c'est une questions de quelques semaines.
C'est surtout autour de la façon d'utiliser que j'ai fait pas mal de changements.
donc, oui attends la 1.3 ça sera plus clair.
c'est une questions de quelques semaines.
aoineko
Membre non connecté
Conseiller Municipal
Je sais pas dans combien de temps Eric pense release la 1.3, mais dans tous les cas, tu ne perdra pas ton temps en prenant en main la 1.2.
Même s'il y a des modifs à apporter à ton programme au passage de la 1.3, le principe du C reste le même.
Et je suis sûr qu'Eric va faire son possible pour que le passage se fasse en douceur #GrossePression
De mon coté, j'ai enfin trouvé pourquoi ma lib ne marchait pas avec les versions récentes de SDCC (>3.0) !!!
Ils ont retiré la mise en pile automatique des paramètres de fonction, même quand elle n'est pas __naked.
Du coup, il faut maintenant gérer ça à la mano en ajoutant :
J'ai check dans Fusion-C, mais c'est déjà ce que tu fais. J'imagine que tu as commencé avec une version >3.0.
Il me reste plus qu'à mettre à jours toute ma lib... joie.
Même s'il y a des modifs à apporter à ton programme au passage de la 1.3, le principe du C reste le même.
Et je suis sûr qu'Eric va faire son possible pour que le passage se fasse en douceur #GrossePression
De mon coté, j'ai enfin trouvé pourquoi ma lib ne marchait pas avec les versions récentes de SDCC (>3.0) !!!
Ils ont retiré la mise en pile automatique des paramètres de fonction, même quand elle n'est pas __naked.
Du coup, il faut maintenant gérer ça à la mano en ajoutant :
Code ASM :
push ix ld ix,#0 add ix,sp ... pop ix
J'ai check dans Fusion-C, mais c'est déjà ce que tu fais. J'imagine que tu as commencé avec une version >3.0.
Il me reste plus qu'à mettre à jours toute ma lib... joie.
On est toujours ignorant avant de savoir.
ericb59
Membre non connecté
Conseiller Municipal
Alors j'ai un problème que je ne sais pas résoudre...
J'ai commencé à convertir la librairie actuelle, pour une utilisation dans le but de compiler en mode ROM.
Pour le moment je test sur des ROM de 32K Classiques.
La plupart de mes fonctions fonctionnent...
Mais j'ai des bugs sur certains examples de codes que je comprend pas.
Je compile avec les paramètres suivant :
--code-loc 0x4050 --data-loc 0xC000
J'utilise le crt0 : crt0_MSX32k_ROM4000.rel
et j'ai ajouté a les paramètres suivant à Hex2Bin : -s 4000 -l 8000
Sur certains examples , à la compilation hex2bin m'indique des erreurs de ce type :
Data record skipped at C0DE
Data record skipped at C0DF
Je ne comprend pas ce que ça veut dire ...
Quelqu'un sait ? aoineko ?
J'ai commencé à convertir la librairie actuelle, pour une utilisation dans le but de compiler en mode ROM.
Pour le moment je test sur des ROM de 32K Classiques.
La plupart de mes fonctions fonctionnent...
Mais j'ai des bugs sur certains examples de codes que je comprend pas.
Je compile avec les paramètres suivant :
--code-loc 0x4050 --data-loc 0xC000
J'utilise le crt0 : crt0_MSX32k_ROM4000.rel
et j'ai ajouté a les paramètres suivant à Hex2Bin : -s 4000 -l 8000
Sur certains examples , à la compilation hex2bin m'indique des erreurs de ce type :
Data record skipped at C0DE
Data record skipped at C0DF
Je ne comprend pas ce que ça veut dire ...
Quelqu'un sait ? aoineko ?
aoineko
Membre non connecté
Conseiller Municipal
Voici les paramètres que j'utilise pour générer les différentes versions de mes jeux :
Y'en a 3 qui t'intéressent :
SDCC --code-loc 0x%CodeAddr% --data-loc 0x%DataAddr%
HEX2BIN -s %StartAddr%
Les crt0 pour les versions DOS et Binary BASIC sont ceux de Konamiman (que tu utilises aussi sur Fusion-C).
Pour ceux des ROMs, c'est moi qui les aient créé mais ils sont super simplistes.
Y a que pour la ROM 32B ou je fais set la Page 2 sur le même slot que celui de la Page 1.
Après, ce qui pourrais poser problème, c'est tous les fichiers .S que tu utilises.
Dans ma lib y en a quasiment pas (tout est encapsulé dans du C).
Je sais pas à quel point ils peuvent changer l'emplacement des différentes sections du code, mais ça me semble possible.
Y a aussi le code __at(0xFFFF) pour les variables en C qui peux poser problème car il force l'emplacement d'une donnée et peut pointer en dehors de la zone allouée pour les datas.
Y'en a 3 qui t'intéressent :
SDCC --code-loc 0x%CodeAddr% --data-loc 0x%DataAddr%
HEX2BIN -s %StartAddr%
Code BASH :
if /I %Target%==BIN ( echo » Target: BASIC binary program ^(8000h~^) set Crt0=crt0_basic set StartAddr=8000 set CodeAddr=8020 set DataAddr=0 set Ext=bin set FillSize=0 set EmulParam=-diska .\emul\dsk ) if /I %Target%==ROM16 ( echo » Target: 16KB ROM in page 1 ^(4000h ~ 7FFFh^) set Crt0=crt0_rom16 set StartAddr=4000 set ROMSize=4000 set CodeAddr=4010 set DataAddr=8000 set Ext=rom set FillSize=16384 set EmulParam=-carta .\emul\%ProjName%.rom ) if /I %Target%==ROM16_2 ( echo » Target: 16KB ROM in page 2 ^(8000h ~ 7FFFh^) set Crt0=crt0_rom16_2 set StartAddr=8000 set ROMSize=4000 set CodeAddr=8010 set DataAddr=C000 set Ext=rom set FillSize=16384 set EmulParam=-carta .\emul\%ProjName%.rom ) if /I %Target%==ROM32 ( echo » Target: 32KB ROM in page 1^&2 ^(4000h ~ BFFFh^) set Crt0=crt0_rom32 set StartAddr=4000 set ROMSize=8000 set CodeAddr=4010 set DataAddr=C000 set Ext=rom set FillSize=32768 set EmulParam=-carta .\emul\%ProjName%.rom ) if /I %Target%==ROM48 ( echo » Target: 48KB ROM in page 0-2 ^(0000h ~ BFFFh^) set Crt0=crt0_rom48 set StartAddr=0000 set ROMSize=C000 set CodeAddr=0410 set DataAddr=C000 set Ext=rom set FillSize=49152 set EmulParam=-carta .\emul\%ProjName%.rom ) if /I %Target%==DOS ( echo » Target: MSX-DOS program ^(starting at 0100h^) set Crt0=crt0_dos set StartAddr=0100 set CodeAddr=0108 set DataAddr=0 set Ext=com set FillSize=0 set EmulParam=-diska .\emul\dos -ext msxdos2 ) if /I %Target%==DOSARG ( echo » Target: MSX-DOS program with command line arguments ^(starting at 0100h^) set Crt0=crt0_dosarg set StartAddr=0100 set CodeAddr=0180 set DataAddr=0 set Ext=com set FillSize=0 set EmulParam=-diska .\emul\dos -ext msxdos2 )
Les crt0 pour les versions DOS et Binary BASIC sont ceux de Konamiman (que tu utilises aussi sur Fusion-C).
Pour ceux des ROMs, c'est moi qui les aient créé mais ils sont super simplistes.
Y a que pour la ROM 32B ou je fais set la Page 2 sur le même slot que celui de la Page 1.
Code ASM :
;------------------------------------------------------------------------------ ; █▀▀ █▀▄▀█ █▀ ▀▄▀ ; █▄▄ █ ▀ █ ▄█ █ █ v0.2 ;------------------------------------------------------------------------------ ; crt0 header for 32KB ROM ; ; Code address: 0x4010 ; Data address: 0xC000 ;------------------------------------------------------------------------------ .module crt0 .globl _main ;------------------------------------------------------------------------------ .area _HEADER (ABS) .org 0x4000 ; ROM header .db 0x41 .db 0x42 .dw init .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 ;------------------------------------------------------------------------------ .area _CODE init: di ld sp, (#0xFC4A) ; Set stack address at the top of memory ; Set Page 2 slot equal to Page 1 slot in a, (#0xA8) and a, #0xCF ld c, a in a, (#0xA8) and a, #0x0C add a, a add a, a or a, c out (#0xA8), a ei call _main ; start main() function rst 0 ;------------------------------------------------------------------------------ ; Ordering of segments for the linker .area _DATA .area _GSINIT .area _GSFINAL
Après, ce qui pourrais poser problème, c'est tous les fichiers .S que tu utilises.
Dans ma lib y en a quasiment pas (tout est encapsulé dans du C).
Je sais pas à quel point ils peuvent changer l'emplacement des différentes sections du code, mais ça me semble possible.
Y a aussi le code __at(0xFFFF) pour les variables en C qui peux poser problème car il force l'emplacement d'une donnée et peut pointer en dehors de la zone allouée pour les datas.
On est toujours ignorant avant de savoir.
ericb59
Membre non connecté
Conseiller Municipal
Merci !
J'ai essayé de compiler avec ton CRT0, mais ça me fait les mêmes erreurs avec hex2bin. De plus la rom n'a pas booté...
J'ai un autre problème, mes routines d'interruptions ne fonctionnent pas en ROM.
Est-ce que tu peux me dire comment tu implémente les interruptions ? (J'ai vraiment un problème de se coté là, j'ai pas trouvé comment c'est censé fonctionner)
J'ai essayé de compiler avec ton CRT0, mais ça me fait les mêmes erreurs avec hex2bin. De plus la rom n'a pas booté...
J'ai un autre problème, mes routines d'interruptions ne fonctionnent pas en ROM.
Est-ce que tu peux me dire comment tu implémente les interruptions ? (J'ai vraiment un problème de se coté là, j'ai pas trouvé comment c'est censé fonctionner)
aoineko
Membre non connecté
Conseiller Municipal
ericb59 :
Est-ce que tu peux me dire comment tu implémente les interruptions ? (J'ai vraiment un problème de se coté là, j'ai pas trouvé comment c'est censé fonctionner)
Comme le reste de ma lib, tout ce qui touche au système est minimaliste.
Voici mes fonctions :
Code C :
// Set a Hook to jump to given function inline void Bios_SetHookCallback(u16 hook, callback cb) { *((u8*)hook) = 0xC3; // JUMP *((callback*)++hook) = cb; } // Clear a Hook (set RET asm code) inline void Bios_ClearHookFunc(u16 hook) { *((u8*)hook) = 0xC9; // RET }
Après, je pense que ça va pas t'aider beaucoup car c'est surtout la fonction appelée par le hook qui est compliqué ; mais ça, ça dépend de ce qu'on y fait.
On est toujours ignorant avant de savoir.
aoineko
Membre non connecté
Conseiller Municipal
Hum... en fait je suis pas sûr d'avoir répondu à la bonne question
Qu'entends-tu par « implémente les interruptions » ?
Qu'entends-tu par « implémente les interruptions » ?
On est toujours ignorant avant de savoir.
ericb59
Membre non connecté
Conseiller Municipal
Je veux parler des fonctions d'implémenter une interruption.
En fait je pensais que celles que j'avais dans la librairie actuelle était "universelle" DOS et ROM, mais apparemment pas.
il y a : interrupt.s et interrupt_vdp.s
là je vois que ta fonction implémente un JP 0xXXXX quelque part... Ca pourrait être sur HTIMI en 0xFD9F ?
Il faut juste faire ça ?
Dans la fonction appelée qu'est-ce qu'il faut éviter au juste ?
(C'est une partie que je en maitrise pas du tout)
Autre
Apparemment les erreurs que j'ai lors de la compilation avec Hex2bin, correspondent à
area _DATA
.area _GSINIT
.area _GSFINAL
du crt0 !
est-il obligé de spécifier le data-loc ?
J'ai fait des tests où ca fonctionnait sans, d'autre non.
Dans le cas d'une ROM 32K, à 0xC000 c'est la RAM. Donc qu'est-ce qu'y va se coller là dedans au juste ?
En fait je pensais que celles que j'avais dans la librairie actuelle était "universelle" DOS et ROM, mais apparemment pas.
il y a : interrupt.s et interrupt_vdp.s
là je vois que ta fonction implémente un JP 0xXXXX quelque part... Ca pourrait être sur HTIMI en 0xFD9F ?
Il faut juste faire ça ?
Dans la fonction appelée qu'est-ce qu'il faut éviter au juste ?
(C'est une partie que je en maitrise pas du tout)
Autre
Apparemment les erreurs que j'ai lors de la compilation avec Hex2bin, correspondent à
area _DATA
.area _GSINIT
.area _GSFINAL
du crt0 !
est-il obligé de spécifier le data-loc ?
J'ai fait des tests où ca fonctionnait sans, d'autre non.
Dans le cas d'une ROM 32K, à 0xC000 c'est la RAM. Donc qu'est-ce qu'y va se coller là dedans au juste ?
aoineko
Membre non connecté
Conseiller Municipal
Pour set un hook sur H.TIMI il suffit d'écrire :
Je connais pas exactement les contraintes (c'était le sujet d'un de mes posts récemment mais j'ai pas eu bcp plus d'infos).
J'ai juste expérimenté des comportements étrange quand mon hook appelait certaines routines du Bios (comme le Beep) à cause de la concurrence (le code du hook peut être redéclencher avant qu'il ait fin de s'exécuter).
Pour limiter les risques, j'ai ajouté des fonctions Mutex pour protéger des zones sensibles de mes hooks.
Voici :
Pour l'utiliser dans un hook
Pour les sections du code assembleur, je maitrise pas trop, mais je vais renseigner.
Ce que j'ai compris, c'est que ça sert à ordonner les différents éléments du programme au moment du link.
Code C :
void MyCallbcak() { // my super intersting code... } Bios_SetHookCallback(H_TIMI, MyCallbcak);
Je connais pas exactement les contraintes (c'était le sujet d'un de mes posts récemment mais j'ai pas eu bcp plus d'infos).
J'ai juste expérimenté des comportements étrange quand mon hook appelait certaines routines du Bios (comme le Beep) à cause de la concurrence (le code du hook peut être redéclencher avant qu'il ait fin de s'exécuter).
Pour limiter les risques, j'ai ajouté des fonctions Mutex pour protéger des zones sensibles de mes hooks.
Voici :
Code C :
//----------------------------------------------------------------------------- // █▀▀ █▀▄▀█ █▀ ▀▄▀ // █▄▄ █ ▀ █ ▄█ █ █ v0.2 //----------------------------------------------------------------------------- #pragma once extern u8 g_Mutex; // Must be declared somewhere in the application code // Initialize mutex inline void MutexInit() { g_Mutex = 0; } // Lock the given mutex (0-7) inline void MutexLock(u8 mutex) { g_Mutex |= (1 << mutex); } // Release the given mutex (0-7) inline void MutexRelease(u8 mutex) { g_Mutex &= ~(1 << mutex); } // Wait for mutex release (0-7) inline void MutexWait(u8 mutex) { while((g_Mutex & (1 << mutex)) != 0); } // Gate for mutex (0-7) inline BOOL MutexGate(u8 mutex) { return ((g_Mutex & (1 << mutex)) == 0); }
Pour l'utiliser dans un hook
Code C :
void MyCallbcak() { if(MutexGate(1)) { MutexLock(1); // codes qui ne peut pas être interrompu... MutexRelease(1); } }
Pour les sections du code assembleur, je maitrise pas trop, mais je vais renseigner.
Ce que j'ai compris, c'est que ça sert à ordonner les différents éléments du programme au moment du link.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie