La Place des Développeurs Megarom Linker pour Fusion-C et autre libraries C :-;
Salut,
aoineko, ca devrait t'intéresser je pense...
Voici comment je vois l'intégration de fichiers binaires et autres pour la création de megarom en C.
Le problème étant que contrairement au logiciels assembleur que les pro de l'ASM utilisent ; avec le C on ne peut pas intégrer directement des fichiers binaires à notre produit finale.
En tout cas, pas directement...
Aoineko utilise une méthode pour sa librairie, voici celle que je vais utiliser pour FUSION-C.
Megalinkv01.zip
Megarom linker (première version béta) que voici ici avec son executable MacOS et sa source (à compiler pour windows) est un outils en ligne de commande qui permet d'insérer des données à l'intérieur d'un fichier. une sorte d'injection de datas...
Imaginons que je souhaite créer une Megarom ASCII16 de 64K
Je code mon jeu... j'ai deux pages de 16K pour y mettre mon code.
Je compile donc mon "coeur" de rom comme étant une ROM ASCII16, mais d'une taille de 32K avec un départ en 0x4000
Codant ce jeux, j'ai créé deux fichiers binaires qui contiennent des graphismes et des données.
Le premier DATA.BIN fait 16K et le second qui contient ma page de sprite IMAGE.SC5 fait aussi 16K
j'ai donc au final ...
JEU.ROM : 32K
DATAS.BIN : 16K
IMAGE.SC5 : 16K
Megarom linker va permettre d'assembler le tout.
megalink -c FINALGAME.ROM 64
(création d'un fichier vide de 64K portant le nom de FINALGAME.ROM
megalink -i JEU.ROM FINALGAME.ROM 0
(Insertion des données de JEU.ROM dans FINALGAME.ROM à l'adresse 0 du fichier)
megalink -i DATA.BIN FINALGAME.ROM 8000
(Insertion des données de DATA.BIN dans FINALGAME.ROM à l'adresse 0x8000 du fichier, ce qui correspond en fait à la première Bank de 1K6 de la megarom ASCII16
megalink -i IMAGE.SC5 FINALGAME.ROM C000
(Insertion des données de IMAGE.?SC5 dans FINALGAME.ROM à l'adresse 0xC000 du fichier, ce qui correspond en fait à la seconde Bank de 16K de la megarom ASCII16
au final on obtient une ROM ASCII16 de 64K avec tous les éléments à leur place.
L'intérêt aussi, est que l'on peut insérer des blocks de données partielles, si on a pas des block de données de 16K, ce n'est pas grave.
Tant qu'on les mets à la bonne place dans le fichier, le mapper s'y retrouvera.
Bien entendu, faut intégrer ça dans le script de compilation...
Si j'ai pas dit de connerie ca devrait le faire.
Perso j'ai testé sur une ROM 48K ca fonctionne bien. Edité par ericb59 Le 19/01/2022 à 15h08
aoineko, ca devrait t'intéresser je pense...
Voici comment je vois l'intégration de fichiers binaires et autres pour la création de megarom en C.
Le problème étant que contrairement au logiciels assembleur que les pro de l'ASM utilisent ; avec le C on ne peut pas intégrer directement des fichiers binaires à notre produit finale.
En tout cas, pas directement...
Aoineko utilise une méthode pour sa librairie, voici celle que je vais utiliser pour FUSION-C.
Megalinkv01.zip
Megarom linker (première version béta) que voici ici avec son executable MacOS et sa source (à compiler pour windows) est un outils en ligne de commande qui permet d'insérer des données à l'intérieur d'un fichier. une sorte d'injection de datas...
Imaginons que je souhaite créer une Megarom ASCII16 de 64K
Je code mon jeu... j'ai deux pages de 16K pour y mettre mon code.
Je compile donc mon "coeur" de rom comme étant une ROM ASCII16, mais d'une taille de 32K avec un départ en 0x4000
Codant ce jeux, j'ai créé deux fichiers binaires qui contiennent des graphismes et des données.
Le premier DATA.BIN fait 16K et le second qui contient ma page de sprite IMAGE.SC5 fait aussi 16K
j'ai donc au final ...
JEU.ROM : 32K
DATAS.BIN : 16K
IMAGE.SC5 : 16K
Megarom linker va permettre d'assembler le tout.
megalink -c FINALGAME.ROM 64
(création d'un fichier vide de 64K portant le nom de FINALGAME.ROM
megalink -i JEU.ROM FINALGAME.ROM 0
(Insertion des données de JEU.ROM dans FINALGAME.ROM à l'adresse 0 du fichier)
megalink -i DATA.BIN FINALGAME.ROM 8000
(Insertion des données de DATA.BIN dans FINALGAME.ROM à l'adresse 0x8000 du fichier, ce qui correspond en fait à la première Bank de 1K6 de la megarom ASCII16
megalink -i IMAGE.SC5 FINALGAME.ROM C000
(Insertion des données de IMAGE.?SC5 dans FINALGAME.ROM à l'adresse 0xC000 du fichier, ce qui correspond en fait à la seconde Bank de 16K de la megarom ASCII16
au final on obtient une ROM ASCII16 de 64K avec tous les éléments à leur place.
L'intérêt aussi, est que l'on peut insérer des blocks de données partielles, si on a pas des block de données de 16K, ce n'est pas grave.
Tant qu'on les mets à la bonne place dans le fichier, le mapper s'y retrouvera.
Bien entendu, faut intégrer ça dans le script de compilation...
Si j'ai pas dit de connerie ca devrait le faire.
Perso j'ai testé sur une ROM 48K ca fonctionne bien. Edité par ericb59 Le 19/01/2022 à 15h08
J'ai enfin trouvé le temps d'analyser le process de création du fichier ROM final.
Je ne sais pas trop ce qu'apporte Megalink, mais en fait, toutes les infos dont on a besoin sont déjà présentes dans le fichier IHX généré par le linker de base de SDCC.
Les segments sont placés à des adresses virtuelles sur 32-bits qui contiennent à la fois le numéro de segment, mais aussi l'adresse ou le segment est censé être visible par le Z80.
Ce qui manque, c'est surtout un outil pour générer le fichier binaire final qui ait connaissance des formats de mapper MSX.
Ca me semble assez facile à faire, du coup je m'en charger.
Cette fois, je vais le faire directement via GCC.
Je ne sais pas trop ce qu'apporte Megalink, mais en fait, toutes les infos dont on a besoin sont déjà présentes dans le fichier IHX généré par le linker de base de SDCC.
Les segments sont placés à des adresses virtuelles sur 32-bits qui contiennent à la fois le numéro de segment, mais aussi l'adresse ou le segment est censé être visible par le Z80.
Ce qui manque, c'est surtout un outil pour générer le fichier binaire final qui ait connaissance des formats de mapper MSX.
Ca me semble assez facile à faire, du coup je m'en charger.
Cette fois, je vais le faire directement via GCC.
On est toujours ignorant avant de savoir.
Salut,
Je pense que tu te places sur un level au dessus du miens, car je ne comprends pas trop de quoi tu parles.
Et souvent dans ces cas là, c'est qu'on ne parle pas vraiment de la même chose.
Dans le cas présent, avec ce petit outil, je cherche juste à placer des DATAs dans les Banks d'une megaRom, rien de plus.
Ici par exemple dans le cas d'une Megarom ascii16, je prend donc pour acquis que le programme C génère un code qui ne dépassera pas 32Ko. Ainsi, il se placera dans les Banks 0 et 1 de la mégarom, soit en Ram dans les adresses 0x4000 à 0xBFFFF. Physiquement ce sont les 32 premiers Ko du fichier.
Disons que mon programme de 32Ko à besoin d'une image .SC5 de 22Ko.
Cette image sera placée à la suite, dans les Banks 2 et 3 de la Megarom AScii16. Physiquement dans le fichier, dans les 16Ko + 6Ko suivant le code binaire généré par SDCC.
Je ne fait que assembler les fichiers, et remplir les espace vide, de manière à obtenir une MegaRom de la Bonne taille.
Lorsque celle-ci sera dans accessible au Z80 dans en tant que ROM. J'aurais donc, les Bank 0 et 1 du programme (0x4000 à 0xBFFFF), et les bancs 2 et 3(0xC000 à 0x13FFF) qui contiendront mon image.
Est-ce que tu souscris à ce que je viens d'expliquer ou pas ?
Je crois que toi tu veux aller plus loin, et permettre d'intégrer du code dans les autres Banks de la Megarom, je me trompe ? Edité par ericb59 Le 29/04/2022 à 16h23
Je pense que tu te places sur un level au dessus du miens, car je ne comprends pas trop de quoi tu parles.
Et souvent dans ces cas là, c'est qu'on ne parle pas vraiment de la même chose.
Dans le cas présent, avec ce petit outil, je cherche juste à placer des DATAs dans les Banks d'une megaRom, rien de plus.
Ici par exemple dans le cas d'une Megarom ascii16, je prend donc pour acquis que le programme C génère un code qui ne dépassera pas 32Ko. Ainsi, il se placera dans les Banks 0 et 1 de la mégarom, soit en Ram dans les adresses 0x4000 à 0xBFFFF. Physiquement ce sont les 32 premiers Ko du fichier.
Disons que mon programme de 32Ko à besoin d'une image .SC5 de 22Ko.
Cette image sera placée à la suite, dans les Banks 2 et 3 de la Megarom AScii16. Physiquement dans le fichier, dans les 16Ko + 6Ko suivant le code binaire généré par SDCC.
Je ne fait que assembler les fichiers, et remplir les espace vide, de manière à obtenir une MegaRom de la Bonne taille.
Lorsque celle-ci sera dans accessible au Z80 dans en tant que ROM. J'aurais donc, les Bank 0 et 1 du programme (0x4000 à 0xBFFFF), et les bancs 2 et 3
Est-ce que tu souscris à ce que je viens d'expliquer ou pas ?
Je crois que toi tu veux aller plus loin, et permettre d'intégrer du code dans les autres Banks de la Megarom, je me trompe ? Edité par ericb59 Le 29/04/2022 à 16h23
ericb59 :
Est-ce que tu souscris à ce que je viens d'expliquer ou pas ?
Les adresses de tes banks (0x4000 à 0xBFFFF et 0xC000 à 0x13FFF) me semblent très étranges.
Pour le reste, ça ressemble à la méthode que j'utilise actuellement.
Le problème que j'essaye de résoudre, c'est de pouvoir linker la ROM de base et tous ses segments en même temps ; ce qui permettra de pouvoir utiliser les symboles (noms de fonction ou de tableau) dans n'importe quel fichier.
La méthode SDCC pour se faire est d'associer des codeseg ("nom de bout de code") à des fichiers.
Par ex. si tu compiles un fichier avec l'option --codeseg SEG1, le code de ce fichier va être marqué comme appartenant à ce segment et au moment du link, tu vas pouvoir associer ce segment (SEG1) à une adresse virtuelle de la forme hexadécimal SSSSAAAA, ou SSSS est le numéro de segment et AAAA l'adresse ou ce segment sera visible par le CPU. Par ex. 00048000 pour le segment 4 visible en 8000h.
En plus de pouvoir accéder aux symboles de tous les segments, ça permet aussi d'utiliser les switch de segment automatique pour les fonctions marqués __banked.
Chose que je ne compte pas utiliser perso (je préfère faire les switch à la main) mais auquel certains semblent compter.
On est toujours ignorant avant de savoir.
Quand j'aurai fini le tool, je ferai un p'tit article sur le wiki pour expliquer le fonctionnement.
Avec des exemples concrets, ça sera beaucoup plus parlant.
Avec des exemples concrets, ça sera beaucoup plus parlant.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie